Ich teste derzeit den Pipeline-Ansatz von Jenkins 2.0, um festzustellen, ob er für die von mir verwendete Build-Umgebung funktioniert.

Zuerst über die Umwelt selbst. Es besteht derzeit aus mehreren SCM-Repositorys. Jedes Repository enthält mehrere Zweige für die verschiedenen Entwicklungsstufen, und jeder Zweig wird mit mehreren Konfigurationen erstellt. Nicht alle Konfigurationen gelten für jedes Repository.

erzeit wird jedes Repository / jeder Zweig als @ eingerichte Matrix Project für die verschiedenen Konfigurationen. Jedes Projekt macht seine Gebäudeergebnisse als Artefakt sichtbar und diese Artefakte werden in den nachgeordneten Projekten verwendet.

Die verschiedenen Repositorys hängen voneinander ab, sodass ein erfolgreicher Aufbau eines Upstream-Jobs einige bestimmte Downstream-Jobs auslöst. Derzeit funktioniert das alles, aber der Arbeitsaufwand zum Einrichten einer neuen Filiale oder zum Optimieren des Bauprozesses ist enorm, da viele verschiedene Projekte von Hand geändert werden müssen.

Nun wollte ich die neuen Pipelines ausprobieren. Meine Idee war, Pipeline-Projekte mit mehreren Zweigen zu erstellen und ein @ zu platziereJenkinsfile im Repository, das die Anweisungen für den Build enthält.

Das Hauptproblem besteht darin, dass sich die Builds gegenseitig auslösen, da im Grunde genommen ein Build in einem bestimmten Upstream-Zweig einen Downstream-Zweig auslösen muss. Dem vorgelagerten Projekt ist jedoch nicht bekannt, welche nachgelagerten Filialen angestoßen werden müssen. Bei jedem Downstream-Projekt werden die Artefakte aus einigen Upstream-Zweigen abgerufen, und die ideale Lösung wäre, wenn der Downstream-Build ausgelöst würde, falls der Upstream-Build, der die Quelle für das Artefakt darstellt, seinen Build abschließt.

Das Problem ist nur, dass die nachgelagerten Projekte wirklich wissen, welche Artefakte sie benötigen. In den meisten Fällen ist es unwahrscheinlich, dass die Filialnamen übereinstimmen, was das Auslösen der Builds aus dem übergeordneten Projekt sehr schwierig macht.

Zurzeit wird dies mit dem @ gelöReverseBuildTrigger. Aber dieses Ding funktioniert nicht mehr, sobald es irgendwo in der Nähe einer Pipeline ist.

Ich bin wirklich ratlos, wie ich das zum Laufen bringen kann. Gibt es eine Möglichkeit, so etwas wie das @ zu bekommeReverseBuildTrigger Arbeiten in Pipeline-Skripten?

Auch das Triggern des gesamten Downstream-Builds für alle Zweige, falls ein einzelner Zweig im Upstream geändert wird, ist keine Option. Dies würde viel zu viele gleiche Builds erzeugen.