Jenkins - Variablen zwischen Jobs übergeben?

Ich habe zwei Jobs in Jenkins, die beide den gleichen Parameter benötigen.

Wie kann ich den ersten Job mit einem Parameter ausführen, sodass beim Auslösen des zweiten Jobs derselbe Parameter verwendet wird?

Sie können das parametrisierte Trigger-Plugin verwenden dem Sie Parameter von einer Aufgabe an eine andere übergeben können.

Sie müssen auch diesen Parameter hinzufügen, den Sie von Upstream in Downstream übergeben haben.

1.Post-Build-Aktionen> Wählen Sie "Parametrisierten Build für andere Projekte auslösen".

2.Geben Sie die Umgebungsvariable mit value ein. Value kann auch Jenkins Build Parameters sein.

Detaillierte Schritte finden Sie hier: -

https://itisatechiesworld.wordpress.com/jenkins-related-articles/jenkins-configuration/jenkins-passing-a-parameter-from-one-job-to-another/

Hoffe es ist hilfreich :)

Die hier akzeptierte Antwort funktioniert für meinen Anwendungsfall nicht. Ich musste in der Lage sein, Parameter in einem Job dynamisch zu erstellen und an einen anderen zu übergeben. Wie Mark McKenna erwähnt, gibt es anscheinend keine Möglichkeit, eine Variable aus einem Shell-Build-Schritt in die Post-Build-Aktionen zu exportieren.

Ich habe eine Problemumgehung mit dem Parameterized Trigger Plugin erreicht, indem ich die Werte in eine Datei geschrieben und diese Datei als Parameter für den Import über 'Post-Build-Aktion hinzufügen' -> 'Parametrized Build auslösen ...' verwendet und dann 'Parameter hinzufügen' ausgewählt habe. > 'Parameter aus Eigenschaftendatei'.

Ich denke, die obige Antwort muss aktualisiert werden:

Ich habe versucht, ein dynamisches Verzeichnis zum Speichern meiner Upstream-Build-Artefakte zu erstellen. Daher wollte ich meine Upstream-Job-Build-Nummer an den Downstream-Job übergeben. Ich habe die obigen Schritte ausgeführt, konnte sie jedoch nicht ausführen. So hat es funktioniert:

1. Ich habe die Artefakte von meinem aktuellen Job mit dem Plugin zum Kopieren von Artefakten kopiert.
2. In der Post-Build-Aktion des Upstream-Jobs habe ich die Variable "SOURCE_BUILD_NUMBER = $ {BUILD_NUMBER}" hinzugefügt und so konfiguriert, dass der Downstream-Job ausgelöst wird.
3. Alles hat funktioniert, außer dass mein Downstream-Job $ SOURCE_BUILD_NUMBER nicht zum Erstellen des Verzeichnisses abrufen konnte.
4. Um diese Variable zu verwenden, muss ich dieselbe Variable im Downstream-Job als Parametervariable wie in der folgenden Abbildung definieren:

Dies liegt daran, dass Sie in der neuen Version von Jenkins die Variable auch im Downstream-Job definieren müssen. Ich hoffe es ist hilfreich.

(für andere Googler)

Wenn Sie eine ernsthafte Pipeline mit dem Build Flow Plugin erstellen , können Sie Parameter zwischen Jobs mit DSL wie folgt übergeben:

Angenommen, ein verfügbarer Zeichenfolgenparameter "CVS_TAG", um ihn an andere Jobs zu übergeben:

build("pipeline_begin", CVS_TAG: params['CVS_TAG'])
parallel (
   // will be scheduled in parallel.
   { build("pipeline_static_analysis", CVS_TAG: params['CVS_TAG']) },
   { build("pipeline_nonreg", CVS_TAG: params['CVS_TAG']) }
)
// will be triggered after previous jobs complete
build("pipeline_end", CVS_TAG: params['CVS_TAG'])

Hinweis zum Anzeigen verfügbarer Variablen / Parameter:

// output values
out.println '------------------------------------'
out.println 'Triggered Parameters Map:'
out.println params
out.println '------------------------------------'
out.println 'Build Object Properties:'
build.properties.each { out.println "$it.key -> $it.value" }
out.println '------------------------------------'

Fügen Sie einfach meine Antwort zusätzlich zu der von Nigel Kirby hinzu, da ich noch keinen Kommentar abgeben kann:

Um einen dynamisch erstellten Parameter zu übergeben, können Sie die Variable auch in die Kachel 'Shell ausführen' exportieren und dann über 'Parametrisierten Build für andere Projekte auslösen' => 'Vordefinierte Parameter' => Geben Sie 'YOUR_VAR = $ YOUR_VAR'. Mein Team verwendet diese Funktion, um die npm-Paketversion vom Build-Job an die Bereitstellungsjobs zu übergeben

UPDATE: oben funktioniert nur für von Jenkins injizierte Parameter. Aus der Shell erstellte Parameter müssen weiterhin dieselbe Methode verwenden. z.B. echo YOUR_VAR = $ {YOUR_VAR}> variable.properties und übergebe diese Datei stromabwärts

Ich hatte das gleiche Problem, als ich eine POM-Version an einen nachgeschalteten Rundeck-Job übergeben musste.

Was ich getan habe, war die Verwendung der Parameterinjektion über eine Eigenschaftendatei als solche:

1) Erstellen von Eigenschaften in der Eigenschaftendatei über die Shell:

Aktionen erstellen:

• Führen Sie ein Shell-Skript aus
• Injizieren Sie Umgebungsvariablen

ZB: Eigenschaftsdefinition

2) Übergeben definierter Eigenschaften an den nachgeschalteten Job: Aktionen nach dem Erstellen:

• Lösen Sie einen parametrisierten Build für ein anderes Projekt aus
• Parameter hinzufügen: Aktuelle Build-Parameter
• Parameter hinzufügen: vordefinierte Parameter

ZB: Eigenschaften senden

3) Es war dann möglich, $ POM_VERSION als solche im nachgeschalteten Rundeck-Job zu verwenden.

/! \ Jenkins Version: 1.636

/! \ Aus irgendeinem Grund musste beim Erstellen des ausgelösten Builds die Option 'Aktuelle Buildparameter' hinzugefügt werden, um die Eigenschaften zu übergeben.

Wenn ich die Antworten durchlese, sehe ich keine andere Option, die mir gefällt, und werde sie auch anbieten. Ich mag die Parametrisierung von Jobs, aber sie lässt sich nicht immer gut skalieren. Wenn Sie Jobs haben, die nicht direkt hinter dem ersten Job, sondern weiter unten in der Pipeline liegen, möchten Sie nicht wirklich jeden Job in der Pipeline parametrisieren, um die Parameter vollständig durchlaufen zu können. Oder wenn Sie eine große Anzahl von Parametern haben, die von einer Vielzahl anderer Jobs verwendet werden (insbesondere diejenigen, die nicht unbedingt an einen übergeordneten oder Master-Job gebunden sind), funktioniert die Parametrisierung erneut nicht.

In diesen Fällen bevorzuge ich die Ausgabe der Werte in eine Eigenschaftendatei und das Einfügen dieser Werte in den von mir benötigten Job mithilfe des EnvInject- Plugins. Dies kann dynamisch erfolgen. Dies ist eine weitere Möglichkeit, das Problem anhand einer anderen Antwort zu lösen, bei der noch parametrisierte Jobs verwendet wurden. Diese Lösung lässt sich in vielen Szenarien sehr gut skalieren.

Sie können dazu den Builder von Hudson Groovy verwenden.

Erster Job in der Pipeline

Zweiter Job in der Pipeline