web-dev-qa-db-fra.com

jenkins échoue à construire un travail en aval

J'essaie de déclencher un travail en aval de mon travail actuel comme ça

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

Le but est d'attendre le résultat du travail et d'échouer ou de réussir 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 pas de paramètres et est défini comme le reste de mes travaux, en utilisant le plugin de pipeline multibranch.

Tout ce que je peux penser, c'est que ce type d'élément jenkins n'est pas pris en charge en tant qu'entrée d'étape de construction, mais cela semble contre-intuitif et se révélerait être un bloqueur pour moi. Quelqu'un peut-il confirmer si tel est bien le cas?

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

Je vous remercie

jenkinscontinuous-integrationcontinuous-deployment
20
omu_negru

J'ai réussi à résoudre ce problème en accordant plus d'attention à la définition de l'étape de génération. Étant donné que tous mes travaux en aval sont définis comme des travaux de pipeline multibranches, leur structure est semblable à un dossier, chaque élément du dossier représentant un travail distinct. Ainsi, la bonne façon 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.

En outre, sans rapport avec la question, mais lié au problème à résoudre, assurez-vous que vous disposez toujours d'au moins un exécuteur supplémentaire sur la machine Jenkins, car la syntaxe d'attente consommera un thread pour le travail en attente et un pour le travail en attente. allumé, et vous pouvez facilement vous retrouver dans une situation de type manque de ressources.

J'espère que cela t'aides

29
omu_negru

Cela ressemble à JENKINS-4544 qui inclut le commentaire

Le pipeline ne prend pas en charge le système de travail en amont/en aval, en partie en raison de limitations techniques, en partie en raison du fait qu'aucune configuration de travail statique ne rendrait cela possible, sauf en inspectant les métadonnées de construction récentes.

Mais il offre également la solution de contournement:

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

À la fin de notre fichier Jenkins et après avoir déclenché le travail, nous attendons qu'il se termine. Dans ce cas, build() renvoie l'objet utilisé pour exécuter le travail en aval. Nous en obtenons les informations.

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)

Ce problème fait partie de JENKINS-2991 , ouvert depuis deux ans:

Actuellement, DependencyGraph est limité à AbstractProject, ce qui empêche les workflows de participer aux relations en amont/en aval (dans les cas où le chaînage des travaux est requis, par exemple en raison de contraintes de sécurité).

Il fait référence à la RFE (Request for Enhancement) JENKINS-37718 , basée sur une autre (sans réponse) Stack Overflow question .

1
VonC