Unser Team benutzt Jenkins und Git. Wir wollen die erweiterte Funktion des Git-Plugins implementieren, die Pre-Builds ermöglicht, bevor Commits in das gesegnete Repository gepusht werden. Siehe Ссылка
Allerdings habe ich Probleme, den gesamten Prozess zu verstehen.
Hier ist ein Auszug:
Richten Sie Ihr Jenkins-Projekt ein, und lassen Sie das Feld 'branch' im Git SCM leer. Dies veranlasst Jenkins, Änderungen in allen Zweigen für das Bauen zu berücksichtigen.
Wählen Sie als nächstes einen bestimmten Zweignamen als Integrationsziel im Bereich 'Erweitert' (z. B. 'Master' oder 'Stable') und wählen Sie 'Vor dem Build zusammenführen'.
Wählen Sie "Push GIT-Tags zurück zum Ursprungs-Repository" aus den Post-Build-Aktionen (dies ist erforderlich, um Ihren zentralisierten git-Repo mit den Ergebnissen des Builds zu aktualisieren).
Jetzt sollten Entwickler niemals direkt zu Ihrem Integrationszweig (der "Master" oder "Stable") wechseln. Stattdessen sollten sie entweder Feature-Zweige verwenden oder beim Commit neue Remote-Zweige erstellen (z. B. "git push origin head: refs / heads / myNewFeature"). Sie könnten auch Ihr GIT-Repository so einrichten, dass es nur Commits für den Integrationszweig von Jenkins akzeptiert.
Du bist fertig. Commits sollten nun automatisch mit dem Integrationszweig zusammengeführt werden (sie werden fehlschlagen, wenn sie nicht sauber zusammengeführt werden) und gebaut. Wenn der Build erfolgreich ist, wird das Ergebnis der Zusammenführung an das Remote-Git-Repository zurückgegeben.
Was ich verstehe, ist
Die Frage ist, wenn der Build fehlschlägt, wie ist der Status des Integrationszweigs? Ich würde nur annehmen, dass es irgendwie zu dem Commit vor der Zusammenführung zurückkehrt. Wenn nicht, dann würde der Integrationszweig die Zusammenführung beibehalten, die den Build zerstört hat, was es unmöglich macht, dass andere Zweige zusammengeführt und gebaut werden.
Stimmt das? Leider ist das nicht klar aus dem Wiki.
Weiß jemand auch von einem Beispiel, das ich betrachten kann?
Was ich von GitSCM.checkout Methode , die Zusammenführung beginnt zuerst mit einem Checkout und, falls die Zusammenführung fehlschlägt, den Kandidatenzweig mit einem anderen Checkout wiederherstellen:
Ich glaube also nicht, dass eine fehlgeschlagene Zusammenführung irgendwelche Konsequenzen für nachfolgende Builds hat.