Ausführen von Tests auf Feature-Zweigen

Question

Ich habe eine Build-Konfiguration mit einem Test VCS-Stamm, der mit Git-Zweig dev, 3 Schritte und 1 Auslöser verbindet. Das sind meine Build-Schritte:

• Build-Tests
• Run Tests
• Build-& Deploy

Ich möchte alle diese Erstellungsschritte für Zweig laufen dev aber nur zwei von ihnen (Erstellen und Ausführen von Tests) für Zweigstellen, die mit feature/* übereinstimmen. Ich möchte, dass dies unter meiner Build-Konfiguration angezeigt wird. Daher hat die Erstellungskonfiguration einen Standardzweig dev, der Tests und Deploys ausführt, aber die zusätzlichen Zweige feature/* führen nur Tests aus.

Wie kann ich das erreichen?

Wenn ich /refs/heads/(feature/*) der Zweigspezifikation hinzufügen (unter Standardzweig), funktioniert das perfekt, aber es wird immer bereitgestellt - was ich nicht will.

Edit 1: scheint es eine Variable %teamcity.build.branch% verfügbar benannt zu sein, die Sie verwenden können. Aber wie wird im Deployment-Schritt eine Bedingung ausgeführt, um zu prüfen, ob der Zweig der Zweig dev ist. Ich bin mir nicht sicher.

Bearbeiten 2: Es gibt auch einen Variablennamen %vcsroot.branch%, der der Name der Standardverzweigung im VCS-Stamm ist. Also brauchen wir noch eine Bedingung, die überprüft, ob die %teamcity.build.branch% Variable %vcsroot.branch% ist, dann den Deployment-Schritt ausführen.

Answer 1

Der Weg, um zu erreichen, was Sie wollen, ist Ihr Build in 2 Builds aufzuteilen und Abhängigkeiten zwischen ihnen zu haben. dann können Sie separate Trigger zwischen den Builds haben.

aufgeteilt, so die Builds so A Sie bauen die

• Build-Tests enthält
• Run Tests

und B aufzubauen, die

• Build-& Deploy
enthält

Geben Sie Build B eine Snapshotabhängigkeit von Build A.

Fügen Sie dann einen Trigger hinzu, um A zu erstellen, wenn ein VCS-Check-in erkannt wird. Dadurch wird sichergestellt, dass der Build und die Tests in jedem Feature-Zweig ausgeführt werden.

Fügen Sie auch einen Trigger für Build B hinzu, wenn ein VCS-Check-In erkannt wird, aber bearbeiten Sie die Regeln, sodass Sie die Feature-Verzweigungen ausschließen.Wenn ein Check-in in einem anderen Zweig erkannt wird, wird Build B gestartet, aber Build A muss zuerst beendet werden, damit es zuerst in die Warteschlange gestellt wird und nicht gestartet wird, wenn Build A fehlschlägt (vorausgesetzt, Sie setzen das in den Optionen).

UPDATE Wenn dies zu viel Aufwand ist dann könnten Sie in der Lage sein, einen kleinen Trick zu spielen, aber ein Build-Schritt zwischen Run Tests und Erstellen und Bereitstellen zu schaffen, die eine Befehlszeile oder Powershell-Skript aufruft. Rufen Sie das Skript an %teamcity.build.branch% übergeben und dann kann das Skript überprüfen, ob es mit dev und Exit 0 aufgerufen wurde, wenn ja, und Exit -1 wenn nicht, und dieser Schritt sollte dann den Build fehlschlagen und die Bereitstellung verhindern. Dies bedeutet, dass der Build fehlschlägt, aber den Schritt verhindert, den Sie vermeiden möchten. Es kann möglich sein, dass teamcity den Build nicht als fehlgeschlagen meldet, wenn dieser Schritt fehlschlägt. Ich bin mir nicht sicher, ob Sie ein Skript schreiben, das das Build und Deploy manuell ausführt und dann dieses Script aufruft in der %teamcity.build.branch% und beenden Sie früh, wenn es nicht dev ist und nur weitermachen, um das eigentliche Build zu tun und zu implementieren, wenn es dev ist. Dies führt nicht zu einem fehlgeschlagenen Build, sondern bedeutet, dass Sie Skripte schreiben müssen, um die Dinge zu tun, die TeamCity jetzt für Sie erledigt.

Answer 2

Sie können dies tun, indem Sie einen Buildschritt "test" (z. B. Powershell-Skript) erstellen, um zu testen, ob Ihr %teamcity.build.branch% mit Ihrem feature/* Muster übereinstimmt. Sie führen nur die folgenden Schritte aus (in diesem Fall Build & Deploy), wenn die vorherigen Schritte erfolgreich waren. Offensichtlich sollte der "Test" -Schritt den Build nicht verfehlen.