5

Je suis en train de déclencher un travail en aval de mon emploi actuel comme sijenkins échoue sur la construction d'un emploi en aval

pipeline { 
    stages { 
    stage('foo') { 
     steps{ 
     build job: 'my-job', propagate: true, wait: true 
     } 
    } 
    } 
} 

Le but est d'attendre le résultat du travail et de l'échec ou réussite en fonction de ce résultat. Jenkins échoue toujours avec le message Waiting for non-job items is not supported. Le travail mentionné ci-dessus n'a aucun paramètre et est défini comme le reste de mes travaux, en utilisant le plugin de pipeline multibranches. Tout ce que je peux penser est que ce type d'article de jenkins n'est pas supporté comme une entrée de construction, mais cela semble contre-intuitif et se révélerait être un bloqueur pour moi. Quelqu'un peut-il confirmer si c'est effectivement le cas?

Si oui, quelqu'un peut-il suggérer des solutions de contournement?

Merci

+1

Je suis à peu près le même problème ici. Malheureusement, le seul autre article que je puisse trouver sur ce sujet est un autre post de StackOverflow d'avril: https://stackoverflow.com/questions/43337070/how-to-invoke-a-jenkins-pipeline-a-in-another-jenkins- pipeline-b –

Répondre

1

Cela ressemble JENKINS-45443 qui comprend le commentaire

Pipeline n'a pas de support pour le système d'emploi en amont/aval, en partie en raison de limitations techniques, en partie en raison du fait que il n'y a pas de configuration de travail statique qui rendrait cela possible, sauf en inspectant les métadonnées de construction récentes.

Mais il offre aussi la solution de contournement:

aussi longtemps que la solution est toujours en cours, j'inclure ici notre solution de contournement. Il est basé dans le rtp (Rich Text Publisher) plugin, que vous devriez avoir installé pour le faire fonctionner:

À la fin de notre Jenkinsfile et après avoir déclenché le travail, nous l'attendons pour finir. Dans ce cas, build() renvoie l'objet utilisé pour exécuter le travail en aval. Nous obtenons l'info de celui-ci.

Avertissement: La fonction getAbsoluteUrl() est critique. Utilisez à vos risques et périls!

def startedBld = build(
    job: YOUR_DOWNSTREAM_JOB, 
    wait: true, // VERY IMPORTANT, otherwise build() does not return expected object 
    propagate: true 
) 

// Publish the started build information in the Build result 
def text = '<h2>Downstream jobs</h2>Started job <a href="' + startedBld.rawBuild.getAbsoluteUrl() + '">' + startedBld.rawBuild.toString() + '</a>' 
rtp (nullAction: '1',parserName: 'HTML', stableText: text) 

Cette question fait partie de JENKINS-29913, ouvert depuis deux ans:

Actuellement DependencyGraph est limité à AbstractProject, ce qui rend impossible pour Workflows de participer à l'amont/aval relations (dans les cas où le chaînage est requis, par exemple en raison de contraintes de sécurité).

Il renvoie le RFE (demande de mise en valeur) JENKINS-37718, basé sur un autre (sans réponse) Stack Overflow question.

7

J'ai réussi à résoudre ce problème en accordant plus d'attention à la définition de l'étape de construction. Comme tous mes travaux en aval sont définis en tant que travaux de pipeline multibranches, leur structure est similaire à celle d'un dossier, chaque élément du dossier représentant un travail distinct. Ainsi, la manière correcte d'appeler les travaux en aval n'était pas build job: 'my-job', propagate: true, wait: true, mais plutôt build job: "my-job/my-branch-name", propagate: true, wait: true.De plus, sans rapport avec la question mais en rapport avec le problème, assurez-vous de toujours disposer d'au moins un exécuteur supplémentaire sur la machine jenkins, car la syntaxe wait on consommera un thread pour le travail en attente et un pour le travail étant attendu, et vous pouvez facilement vous retrouver dans une situation de type de famine.

J'espère que cela aide

+0

Donc le bug que j'ai mentionné ne s'applique pas ici? +1 de toute façon. – VonC