O mnieBlogGitHub

Azure Pipelines - uważaj na stages i jobs

22 October, 2019 - 2 min read

Odkąd Azure Pipelines (lub szerzej - Azure Devops) umożliwił deklarowanie pipeline'ów w plikach YAML zamiast klikania po stronie - bardzo spodobał mi się ten sposób organizacji CI/CD. Mimo że struktura YAML-a jest przejrzysta, umożliwia składanie procesu budowania/wdrazania z klocków i w zasadzie koncepcyjnie odzwierciedla to, co dało się zrobić w wersji UI-owej - to jednak o pomyłkę łatwo.

Ostatnio dużo czasu spędziłem na tym, że wysypywał mi się bardzo prosty pipeline: w zasadzie tam było tylko w pierwszym kroku zbudowanie projektu przez npm install; w drugim zaś kroku: uruchomienie testów UI, napisanych z pomocą biblioteki Cypress. Mimo że wszystkie skrypty były poprawnie zdefiniowane, build agent też miał wszystko, co było potrzebne i wszystko działało na maszynie deweloperskiej, to Azure Devops potykał się na drugim kroku, stwierdzając, że cypress not found. Sprawdzałem pathy, kombinowałem z różnymi opcjami, ale nic nie chciało działać. Okazało się finalnie, że - krok pierwszy (npm install) i drugi zdefiniowałem jako oddzielne joby w ramach jednego stage'a. (Czyli miałem jeden stage, z dwoma jobami, a w każdym jobie po jednym stepie.) No i nie uwzględniłem tego, że joby są od siebie niezależne, a zatem stworzony w pierwszym kroku folder node_modules nie był dostępny w drugim jobie. Czyli de facto próbowałem uruchomić skrypt npm (do uruchomineia Cypressa) bez wcześniejszego odpalnia npm install. Na świeżo sklonowanym repo to nie może się udać.

Na przyszłość warto więc pamiętać, jaka jest struktura pipeline'a:

STAGE 1
   - JOB 1
     - STEP 1
     - STEP 2
     ...
   - JOB 2
     - STEP 1
     ...

Przykładowo można to sobie wytłumaczyć tak:

  • stages służą do oddzielenia głównych operacji, np. budowania od wdrażnia
  • joby są poiom niżej i "enkapsulują" jakiś konkretny kawałek takiego dużego procesu, czyli np. jeśli budujemy oddzielnie frontend i backend, to możemy mieć w dwa joby na to; joby możemy puszczać równolegle albo określać, że dany job ma czekać wynik innego joba
  • stepy to już kolejne kroki w ramach danego joba, np. npm install, potem npm run build.

Wyniki z jednego joba można dzielić z innymi, ale trzeba to zrobić poprzez pipeline artefacts.