Always Returns Success – dlaczego? Jenkins i PowerShell

Od jakiegoś czasu mam przyjemność obcować z narzędziem typu Continuous Integration i Continuous Delivery, a konkretnie mowa o Jenkins. Chciałbym podzielić się swoimi spostrzeżeniami a w obszarze tego narzędzia w zestawie z pluginem PowerShell, którego główie używam. Dzisiaj będzie o…

Always Returns Success

Temat w Google przewija się właśnie pod takim hasłem, zawsze sukces mimo, błędnego wykonania bloku skryptu PowerShell. Poniżej pokaże na przykład, o co dokładnie chodzi i jak to „widzi” Jenkins. Na początku stworzyłem banalny skrypt z obsługą błędu oraz ustawioną zmienną $ErrorActionPreference na Stop. Dodałem go, jako jeden krok w jobie i uruchomiłem.

Jenkins zgłasza sukces, który nijak ma się to do rzeczywistości.

Jenkins w takiej sytuacji nie robi nic innego weryfikuję tak zwany exit code. W PowerShell taki kod wyjścia zapisywany jest do zmiennej $LASTEXITCODE. Natomiast w powłoce systemowej (CMD) do %errorlevel%. Aby sprawdzić, jaki exit code jest zwracany po wykonaniu skryptu, zapisałem go do pliku ps1 i wywołałem z CMD w podobny sposób jak to robi Jenkins.

Sprawdzę zmienną %errorlevel% i otrzymujemy:

0 (0x0) – ERROR_SUCCESS –  The operation completed successfully.

OK, wiemy, czemu tak się dzieje, ale jak sobie z tym poradzić? Jak obsłużyć błąd, aby był błędem?

Mr. Throw

Kluczem poprawnej obsługi błędów i zwracanych wyników jest użycie polecenia Throw,  którym jesteśmy wstanie rzutować błąd wyjścia. Mała modyfikacja w skrypcie, dodanie w bloku catch{} polecenia throw 1.

Ponowne wywołanie joba w CI i wreszcie, uprawgniony FAILURE 🙂

 

Z pasją poświęcam czas na zdobywanie wiedzy w zakresie szeroko rozumianej Data Platform. Zachwycony językiem skryptowym Windows PowerShell. Swoją wiedzę, doświadczenia i spostrzeżenia opisuję na blogu.

Leave a Reply

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *