2016-02-16 7 views
6

Aus meinen Beobachtungen, wie TeamCity funktioniert, habe ich bemerkt, dass Build-Fehlerbedingungen ausgewertet werden, nachdem alle Schritte ausgeführt wurden. Das ist ziemlich ärgerlich, da ich keinen Schritt ausführen kann, der nicht ausgeführt werden würde, wenn eine der Build-Fehlerbedingungen erfüllt wäre.TeamCity-Schritt muss bei Build-Fehlerbedingung übersprungen werden

Ich beziehe mich nicht auf die allgemeinen Build-Fehlerbedingungen, wie "mindestens ein Test fehlgeschlagen". Ich beziehe mich auf die manuell hinzugefügten Fehlerbedingungen, z. B. auf die Änderung der Metrik.

Wenn ich das Build-Protokoll überprüfe, sehe ich klar, dass alle Schritte ausgeführt werden, und nur am Ende wertet es die Build-Fehler-Bedingungen aus und protokolliert die entsprechenden Fehler, falls vorhanden. Aber das ist zu spät im Prozess, da der bedingte Schritt (der basierend auf "Nur ausführen, wenn der Build-Status erfolgreich ist" fehlschlagen musste) bereits ausgeführt wurde.

Frage: Wie kann ich das erreichen?

Wie Sie oben sehen können, habe ich bereits versucht, einen bedingten Schritt zu haben und die Build-Fehlerbedingung hinzugefügt, kann aber nicht das gewünschte Ergebnis erzielen.

Addition der Übersichtlichkeit halber:

Grundsätzlich habe ich einen Schritt, der die Anwendung einsetzt. Ich erwarte jedoch, dass ich nicht bereitstellen sollte, wenn die Build-Fehlerbedingungen erfüllt sind. Beispiel für Build-Fehler-Bedingungen, die ich habe, ist eine Änderung der Metrik. Offensichtlich kann ich dies als Build-Fehler-Bedingung ausdrücken, und ich kann den Build-Schritt haben, der fehlschlägt, falls der Build-Status nicht erfolgreich ist. Es sieht jedoch so aus, als würde sich der Build-Schritt nicht so verhalten, weshalb ich verwirrt bin (ich dachte, das ist der Zweck der Bedingung im Build-Schritt). Was vermisse ich?

Antwort

0

Dies liegt daran, dass Build-Fehlerbedingungen geprüft werden, wenn alle Build-Schritte abgeschlossen sind. Und es macht Sinn, denn für eine Bedingung wie metrische Änderung sollten Sie warten, bis der Build abgeschlossen ist. Ich meine, Sie können die Artefaktgröße nicht berechnen oder nach einem bestimmten Text in Protokollen oder ähnlichem suchen, bis der Build abgeschlossen ist.

Das heißt - für Ihren Fall, Sie schriftlich Build mit einem Nicht-Null-Exit-Code auf Fehler, die Ausfahrt Schritte in Betracht ziehen sollten, und dann können Sie If all previous steps finished successfully Option in Execute step von build step verwenden.

+0

Sie schlagen also vor, dass der Schritt mit Komponententests mit einem Code ungleich Null beendet werden sollte, wenn die Bedingungen für den Buildfehler erfüllt sind? aber wie kann ich Schritt sagen, um Code zurückzugeben, der nicht Null ist, basierend auf den Build-Fehlerbedingungen? – Tengiz

+0

Nicht aufgrund von Build-Fehlerbedingungen - Wenn Sie Unit-Tests ausführen und ein Komponententest fehlschlägt, sollte der Schritt, der Unit-Tests ausführt, einen Exit-Code ungleich Null zurückgeben. Vielleicht ein bisschen mehr Informationen darüber, wie Sie laufende Unit-Tests werden hilfreich sein. Wenn Sie beispielsweise das teamcity-NUnit-Plug-In verwenden, um Nunit-Tests auszuführen, wird es mit einem Nicht-Null-Exit-Code beendet, wenn ein Test fehlschlägt. –

+0

Ich habe Ihren Standpunkt verstanden. Unit-Tests schlagen jedoch nicht fehl, nur die Build-Fehlerbedingung ist wahr. Das bedeutet: Alle Komponententests bestanden, aber die Abdeckung sank um N Prozent. Ich habe eine Build-Fehler-Bedingung, die überprüft, ob die Abdeckung fallengelassen wurde, und wenn sie abbrach, wird der Build als fehlgeschlagen markiert. Unit-Tests scheitern jedoch nicht. Am Ende des Builds wird es als fehlgeschlagen markiert, sodass die Buildfehlerbedingung einwandfrei funktioniert. Ich muss nur den letzten Schritt (Deployment) überspringen, wenn die Abdeckung fallengelassen wurde (bedeutet, dass die Build-Fehlerbedingung erfüllt ist). – Tengiz

Verwandte Themen