Wie wird der TeamCity-Trigger eingerichtet, um mit Änderungen am git-Submodul zu beginnen?
Derzeit müssen Sie einen Submodul-Commit-Zeiger aktualisieren, um einen Build im Haupt-Repository auszulösen, damit TC eine Änderung im Haupt-Repository registriert.
Aktualisieren
Das Problem ist, dass das Submodul immer einen Zweig-Master verfolgen sollte. AFAIK das kann nicht durch git selbst erreicht werden. Ich möchte nur, dass der Build die Git-Beschränkung in dieser Angelegenheit überwindet.
Dies ist keine saubere Lösung, aber es wird ein Ziel erreicht, ein Projekt mit der Spitze des Submoduls zu erstellen und Submodule nicht manuell aktualisieren zu müssen. (Ein Haken würde wahrscheinlich tun)
Erstellen Sie eine separate Build-Konfiguration mit dem Submodul als Hauptrepo, und richten Sie einen Befehlszeilen-Buildschritt ein, um einen Master-Repo zu klonen, das Submodul zu ziehen / zu aktualisieren und den aktualisierten Submodulzeiger zurück zum Master-Repo zu schieben. p> %Vor%
Ich bin neu bei Git, also kann das wahrscheinlich optimiert werden.
Das ist nicht möglich, da TeamCity (und git) nicht wissen kann, dass es ein Update gibt. Der Submodul-Eintrag in einem Repo zeigt nur auf einen Commit.
Was wäre ein Update dazu? Es kann mehrere Zweige und Commits von diesem Commit geben. Nur Sie können entscheiden, wo das Submodul aktualisiert werden soll.
Ich habe gerade versucht, dasselbe mit TeamCity zu erreichen, aber ich habe schnell festgestellt, dass es keinen Sinn macht, es zu tun. Ihr TeamCity-Build sollte auf dem basieren, was sich in Ihrem Master-Repository befindet. Wie Sie sagen, hängt die Art und Weise, wie GIT-Submodule arbeiten, vom Master-Repository ab, um den Zeiger auf das neue Commit im Unter-Repository zu aktualisieren .
Unterm Strich möchte ich nicht, dass TeamCity etwas erstellt, das ich nicht aus der Quelle wiederherstellen kann, d. h. das Klonen des Master-Repositorys spiegelt nicht wider, was TeamCity tatsächlich erstellt hat.
Tags und Links git teamcity teamcity-8.0