2012-11-15 18 views
6

Ich baue eine Qt GUI-Anwendung über Jenkins. Ich habe 3 Build Schritte:Jenkins Build Script beendet nach Google Testausführung

  • Aufbau der Test ausführbaren
  • den Test ausführbare Lauf
  • eine Abdeckung Bericht mit gcovr

Aus irgendeinem Grund Kompilieren der Shell Aufgabe für die Durchführung des Tests ausführbar stoppt nach der Ausführung. Selbst eine einfache echo läuft nicht nach. Die Tests werden mit Google Test geschrieben und xUnit XML-Dateien ausgegeben, die nach dem Build analysiert werden. Einige Tests starten die Benutzeroberfläche der Anwendung, also habe ich das jenkins xvnc-Plugin installiert, damit sie ausgeführt werden können.

Die Build-Aufgaben sind wie folgt:

Bauen

cd $WORKSPACE/projectfiles/QMake 
sh createbin.sh 

-Test

cd $WORKSPACE/bin 
./Application --gtest_output=xml 

Deckungsbericht

cd $WORKSPACE/projectfiles/QMake/out 
gcovr -x -o coverage.xml 

Nun wird eine echo am Ende der ersten Build-Aufgabe korrekt gedruckt, aber eine echo am Ende der zweiten ist nicht korrekt. Die dritte Build-Task wird daher nicht einmal ausgeführt, obwohl die Google Test-Ausgabe sichtbar ist. Ich dachte, dass das Problem vielleicht darin besteht, dass einige Google Tests fehlschlagen, aber warum sollte das Skript nicht ausgeführt werden, nur weil die Tests fehlschlagen?

Vielleicht kann mir jemand einen Hinweis geben, warum die zweite Aufgabe aufhört.

bearbeiten

Die Konsolenausgabe sieht wie folgt aus:

Updating svn://repo/ to revision '2012-11-15T06:43:15.228 -0800' 
At revision 2053 
no change for svn://repo/ since the previous build 
Starting xvnc 
[VG5] $ vncserver :10 

New 'ubuntu:10 (jenkins)' desktop is ubuntu:10 

Starting applications specified in /var/lib/jenkins/.vnc/xstartup 
Log file is /var/lib/jenkins/.vnc/ubuntu:10.log 

[VG5] $ /bin/sh -xe /tmp/hudson7777833632767565513.sh 
+ cd /var/lib/jenkins/workspace/projectfiles/QMake 
+ sh createbin.sh 
... Compiler output ... 
+ echo Build Done 
Build Done 
[VG5] $ /bin/sh -xe /tmp/hudson4729703161621217344.sh 
+ cd /var/lib/jenkins/workspace/VG5/bin 
+ ./Application --gtest_output=xml 
Xlib: extension "XInputExtension" missing on display ":10". 
[==========] Running 29 tests from 8 test cases. 
... Test output ... 
3 FAILED TESTS 
Build step 'Execute shell' marked build as failure 
Terminating xvnc. 
$ vncserver -kill :10 
Killing Xvnc4 process ID 1953 
Recording test results 
Skipping Cobertura coverage report as build was not UNSTABLE or better ... 
Finished: FAILURE 

Antwort

22

Im Allgemeinen, wenn ein Build-Schritt fehlschlägt, wird der Rest nicht ausgeführt werden.

Achten Sie auf diese Zeile aus dem Protokoll:

[VG5] $ /bin/sh -xe 

Die -x macht den Shell Druck jeden Befehl in der Konsole vor der Ausführung.
Die -e bewirkt, dass die Shell mit einem Fehler beendet wird, wenn einer der Befehle fehlgeschlagen ist.

Ein "Fehler" in diesem Fall wäre ein Rückgabecode von keinem der einzelnen Befehle.
Sie können dies überprüfen, indem Sie diese direkt auf der Maschine läuft:

./Application --gtest_output=xml 
echo $? 

Wenn die echo $? Displays 0, gibt es den erfolgreichen Abschluss des vorherigen Befehls. Wenn es etwas anderes anzeigt, zeigt es einen Fehlercode vom vorherigen Befehl an (von./ Anwendung), und Jenkins behandelt es als solches.

Jetzt sind hier einige Dinge im Spiel. Erstens ist Ihr zweiter Build-Schritt (im Wesentlichen ein temporäres Shell-Skript /tmp/hudson4729703161621217344.sh) so eingestellt, dass er fehlschlägt, wenn ein Befehl fehlschlägt (das Standardverhalten). Wenn der Build-Schritt fehlschlägt, wird Jenkins stoppen und den gesamten Job verpassen.

Sie können dieses spezielle Verhalten beheben, indem Sie set +e oben in Ihrem zweiten Build-Schritt hinzufügen. Dies führt nicht dazu, dass das Skript (Build-Schritt) aufgrund eines einzelnen Befehlsfehlers fehlschlägt (es wird ein Fehler für den Befehl angezeigt und es wird fortgefahren).

Das Gesamtergebnis des Skripts (Build-Schritt) ist jedoch der Exit-Code des letzten Befehls. Da in Ihrem OP nur zwei Befehle im Skript vorhanden sind und die letzte fehlschlägt, führt dies dazu, dass das gesamte Skript (Build-Schritt) trotz der von Ihnen hinzugefügten +x als Fehler betrachtet wird. Beachten Sie, dass dies funktioniert, wenn Sie einen echo als 3. Befehl hinzufügen, da der letzte Skriptbefehl (echo) erfolgreich war, jedoch ist diese "Abhilfe" nicht das, was Sie brauchen.

Was Sie brauchen, ist die richtige Fehlerbehandlung, die Ihrem Skript hinzugefügt wurde. Bedenken Sie:

set +e 
cd $WORKSPACE/bin && ./Application --gtest_output=xml 
if ! [ $? -eq 0 ]; then 
    echo "Tests failed, however we are continuing" 
else 
    echo "All tests passed" 
fi 

Drei Dinge sind im Skript passiert:

  1. Erstens haben wir Shell mit, nicht bei Ausfall einzelner Befehle zu beenden

  2. Dann habe ich hinzugefügt Grund Fehlerbehandlung in der zweiten Zeile. Die && bedeutet "execute ./Application if-and-only-wenn die vorherige cd war erfolgreich. Sie wissen nie, vielleicht fehlt der bin-Ordner, oder was auch immer sonst passieren kann. BTW, arbeitet die && intern auf den gleichen Fehlercode gleich 0 Prinzip

  3. Schließlich gibt es jetzt eine korrekte Fehlerbehandlung für das Ergebnis ./Application.Wenn das Ergebnis nicht 0 ist, dann zeigen wir, dass es fehlgeschlagen ist, sonst zeigen wir, dass es bestanden hatte. Beachten Sie, dies seit dem letzten Befehl ist kein (potentiell) fehlgeschlagener ./Application, aber ein echo aus einer der Möglichkeiten von if-else, wird das Gesamtergebnis des Skripts (Erstellter Schritt) ein Erfolg sein (dh 0), und der nächste Erstellungsschritt wird ausgeführt

BTW, Sie können auch alle 3 Ihrer Build-Schritte in einen einzigen Build-Schritt mit richtiger Fehlerbehandlung setzen.

Ja ... diese Antwort ist vielleicht ein wenig länger als das, was benötigt wird, aber ich wollte, dass Sie verstehen, wie Jenkins und Shell Exit-Codes behandeln.

+1

Ausgezeichnete Antwort, ich dachte wirklich nicht über die Möglichkeit, dass jeder der möglichen Befehle das Skript stoppen könnte. Vielen Dank! – dasmaze

+1

Ich wünschte, ich könnte Sie 10 mal auffrischen. Thks viel dafür !!! – nolazybits

+0

@zeflasher, du könntest mir immer ein Kopfgeld für die Antwort zuweisen;) – Slav