{"componentChunkName":"component---src-templates-blog-post-js","path":"/blog/azure-pipelines-uwazaj-na-stages-i-jobs","result":{"data":{"markdownRemark":{"html":"<p>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.</p>\n<p>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 <code class=\"language-text\">npm install</code>; 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 <code class=\"language-text\">cypress not found</code>. Sprawdzałem pathy, kombinowałem z różnymi opcjami, ale nic nie chciało działać. Okazało się finalnie, że - krok pierwszy (<code class=\"language-text\">npm install</code>) 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 <code class=\"language-text\">node_modules</code> nie był dostępny w drugim jobie. Czyli <em>de facto</em> próbowałem uruchomić skrypt npm (do uruchomineia Cypressa) bez wcześniejszego odpalnia <code class=\"language-text\">npm install</code>. Na świeżo sklonowanym repo to nie może się udać.</p>\n<p>Na przyszłość warto więc pamiętać, jaka jest struktura pipeline'a:</p>\n<div class=\"gatsby-highlight\" data-language=\"text\"><pre style=\"counter-reset: linenumber NaN\" class=\"language-text line-numbers\"><code class=\"language-text\">STAGE 1\n   - JOB 1\n     - STEP 1\n     - STEP 2\n     ...\n   - JOB 2\n     - STEP 1\n     ...</code><span aria-hidden=\"true\" class=\"line-numbers-rows\" style=\"white-space: normal; width: auto; left: 0;\"><span></span><span></span><span></span><span></span><span></span><span></span><span></span><span></span></span></pre></div>\n<p>Przykładowo można to sobie wytłumaczyć tak:</p>\n<ul>\n<li>stages służą do oddzielenia głównych operacji, np. budowania od wdrażnia</li>\n<li>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</li>\n<li>stepy to już kolejne kroki w ramach danego joba, np. <code class=\"language-text\">npm install</code>, potem <code class=\"language-text\">npm run build</code>.</li>\n</ul>\n<p>Wyniki z jednego joba można dzielić z innymi, ale trzeba to zrobić poprzez <em>pipeline artefacts</em>.</p>","excerpt":"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…","frontmatter":{"date":"22 October, 2019","path":"/blog/azure-pipelines-uwazaj-na-stages-i-jobs","title":"Azure Pipelines - uważaj na stages i jobs"},"fields":{"readingTime":{"text":"2 min read"}}}},"pageContext":{}},"staticQueryHashes":["3649515864","63159454"]}