web-dev-qa-db-fra.com

Renvoyer les paramètres/résultats d'un travail (déclenché par pipeline) dans le même pipeline

Pipeline Jenkins: J'ai un pipeline p1 qui déclenche un travail j1, puis un travail j2. Je veux des paramètres définis par j1 et passés à j2 dans le pipeline p1. Comment implémenter cette fonctionnalité à l'aide du plug-in de pipeline Jenkins? Merci d'avance

jenkinsjenkins-pipeline
12
Sid.R

Cela peut être fait en utilisant "env". Si vous parvenez à faire j1 ajouter ses informations dans la env de la construction.

Si j1 était un pipeline, vous pourriez env.MYKEY=MYVALUE. Pour un travail en style libre, cela devrait fonctionner avec le plugin EnvInject (n'a pas essayé). Dans p1, vous obtiendrez une carte avec ces informations si vous ne vous retrouvez pas dans le résultat de la construction.

Donc, si vous faites dans p1 quelque chose comme ceci:

// somewhere in your pipeline, i.e. p1:
def j1BuildResult = build job: 'J1'
def j1EnvVariables = j1BuildResult.getBuildVariables();

alors j1EnvVariables sera une carte contenant les variables que vous avez définies dans j1.

PS: comment transmettre cette information en tant que paramètre p2, par exemple. couvert ici .

13
tobi42

J'ai eu un problème similaire. Je devais le faire en demandant aux travaux J1, J2 de créer des fichiers de propriétés, puis d’acquérir ces fichiers à l’aide de "Copier l’artifact" dans le pipeline principal P1. Convertissez ensuite les propriétés en propriétés Java (ce qui peut nécessiter une approbation de script dans Jenkins). Ce serait bien si le pipeline Jenkins pouvait renvoyer des paramètres directement dans le code (il est peut-être possible de le faire, mais je ne le sais pas). Le retour d'une étape de construction est un RunWrapper , il ne semble pas avoir le moyen de renvoyer un résultat personnalisé visible (à moins d'utiliser une propriété existante telle que la description de la construction).

Alors j'ai eu quelque chose comme ça:

// Pipeline code in P1

// Build J1 and get result. 
def j1BuildResult = build job: 'J1', parameters: [string(name: 'J1_PROP', value: 'FOO')], propagate: true, wait: true

// Get results of J1
step([$class              : 'CopyArtifact', filter: 'j1-result.properties',
      fingerprintArtifacts: true,
      flatten             : true,
      projectName         : 'J1',
      selector            : [$class     : 'SpecificBuildSelector', buildNumber: buildResult.getNumber().toString()]])

// Load J1 properties (you may need to turn off sandbox or approve this in Jenkins)
Properties j1Props = new Properties()
j1Props.load(new StringReader(readFile('j1-result.properties')))

// Build J2
def j2BuildResult = build job: 'J2', parameters: [string(name: 'J2_PROP', value: j1Props.someProperty)], propagate: true, wait: true

// Get results of J2
step([$class              : 'CopyArtifact', filter: 'j2-result.properties',
      fingerprintArtifacts: true,
      flatten             : true,
      projectName         : 'J2',
      selector            : [$class     : 'SpecificBuildSelector', buildNumber: buildResult.getNumber().toString()]])

// Load J2 properties (you may need to turn off sandbox or approve this in Jenkins)
Properties j2Props = new Properties()
j1Props.load(new StringReader(readFile('j2-result.properties')))
8
macg33zr

Vous pouvez obtenir les paramètres de construction avec les variables d’environnement using

def buildProperties = runWrapper.rawBuild.getEnvironment()

C'est une carte groovy. Les paramètres cibles peuvent être reçus avec

String someProperty = buildProperties.someProperty

Restrictions: il faut autoriser method hudson.model.Run getEnvironment dans "Approbation de script en cours de traitement" et appeler ce code dans node fermeture (en raison de rawBuild).

J'ai aussi essayé runWrapper.rawBuild.getAction(ParametersAction.class) mais cela nécessite de nombreuses importations dans Jenkinsfile.

Remarque: runWrapper.getBuildVariables() ne renvoie rien pour moi.

3
AlexMakarov

Vous pouvez obtenir le résultat du pipeline de construction en

def myjob=build job: 'testy', propagate: true, wait: true, parameters: [string(name: 'ENV', value: 'jamshaid'), string(name: 'Repo', value: 'khalid')]
echo "${myjob.getResult()}"
0
Khalid Bin Huda

Ma première réponse n’est pas exactement une réponse à votre question. Cependant, j’essayais de faire quelque chose de similaire, mais j’avais besoin d’une réponse «oui/non» à une question.

Ma deuxième réponse pourrait vous aider, ou aider les autres, comme cela fonctionnerait ...

Première réponse: Exécutez un sous-travail qui «échoue pour une réponse« non »et« réussit pour une réponse «oui».

Assurez-vous simplement de définir 'propagate: false' dans l'exécution de votre travail. Voici un copier/coller:

            def getos = build job: 'internal_is_Host_running_linux',
                parameters: [[$class: 'StringParameterValue',
                  name:'Host',value: Host]],propagate: false,wait:true
            def linuxTest = getos.getResult()
            if (linuxTest != "SUCCESS") {
                     // NOT success, meaning NOT booted Linux

Je suis sûr qu'il existe 100 meilleures façons de le faire, mais cela fonctionne.

La deuxième solution qui pourrait fonctionner serait d'obtenir la sortie console du sous-travail et de rechercher les données souhaitées.

Voici comment obtenir la sortie de la console du sous-job. Au moins, cela a fonctionné pour moi:

            def job = build job: 'internal_run_remote_command',
               wait: true, propagate: false,
               parameters: [[$class: 'StringParameterValue',
                      name: 'Host', value: Host],
                 [$class: 'StringParameterValue',
                      name: 'stageos', value: stageos]]
            // put the standard output from the subjob into our output:
            def checklog2 = job.rawBuild.log
            // obviously, if you don't want the output in your console, do not println
            println checklog2

Évidemment, au lieu de 'println checklog2', vous pouvez le rechercher à votre guise. Ceci est un exercice laissé au lecteur ;-)

(Encore une fois, il y a probablement 100 meilleures façons de le faire, mais cela a fonctionné pour moi)

Mon environnement: utiliser exclusivement des pipelines. L'hôte principal doit exécuter le script de pipeline, mais de temps en temps, il doit exécuter quelque chose sur un autre hôte, tout en restant sur l'hôte principal. Les sous-travaux semblent donc être la solution pour moi jusqu'à présent.

0
RustyCar