Sekwencja uruchamiania potoku

  • Artykuł

Azure DevOps Services | Azure DevOps Server 2022 r. — Azure DevOps Server 2019 r.

Uruchomienia reprezentują jedno wykonanie potoku. Podczas uruchamiania potok jest przetwarzany, a agenci przetwarzają co najmniej jedno zadania. Uruchomienie potoku obejmuje zadania, kroki i zadania. Uruchamia potoki ciągłej integracji i ciągłego dostarczania (CD).

Omówienie potoku

Po uruchomieniu potoku wiele rzeczy dzieje się pod osłonami. Chociaż często nie trzeba o nich wiedzieć, czasami warto mieć duży obraz. Na wysokim poziomie usługa Azure Pipelines będzie:

Po stronie agenta dla każdego zadania agent będzie:

Zadania mogą zakończyć się powodzeniem, niepowodzeniem lub anulować. Istnieją również sytuacje, w których zadanie może nie zostać ukończone. Zrozumienie, jak to się stanie, może pomóc w rozwiązywaniu problemów.

Podzielmy każdą akcję na jedną.

Przetwarzanie potoku

Rozwiń szablony YAML

Aby przekształcić potok w przebieg, usługa Azure Pipelines przeprowadzi kilka kroków w następującej kolejności:

  1. Najpierw rozwiń szablony i oceń wyrażenia szablonu.
  2. Następnie oceń zależności na poziomie etapu , aby wybrać pierwsze etapy do uruchomienia.
  3. Dla każdego etapu wybranego do uruchomienia zdarzają się dwie rzeczy:
  4. Dla każdego zadania wybranego do uruchomienia rozwiń wielokonfiguracje (strategy: matrix lub strategy: parallel w języku YAML) do wielu zadań środowiska uruchomieniowego.
  5. Dla każdego zadania środowiska uruchomieniowego należy ocenić warunki , aby zdecydować, czy to zadanie kwalifikuje się do uruchomienia.
  6. Zażądaj agenta dla każdego kwalifikującego się zadania środowiska uruchomieniowego.

Po zakończeniu zadań środowiska uruchomieniowego usługa Azure Pipelines zobaczy, czy istnieją nowe zadania kwalifikujące się do uruchomienia. Jeśli tak, kroki 4–6 powtórzą się z nowymi zadaniami. Podobnie, gdy etapy zostaną ukończone, kroki 2–6 zostaną powtórzone dla wszystkich nowych etapów.

Ta kolejność pomaga odpowiedzieć na typowe pytanie: dlaczego nie mogę używać pewnych zmiennych w parametrach szablonu? Krok 1, rozszerzenie szablonu, działa wyłącznie na tekście dokumentu YAML. Zmienne środowiska uruchomieniowego nie istnieją podczas wykonywania tego kroku. Po wykonaniu kroku 1 parametry szablonu zostały rozpoznane i już nie istnieją.

Odpowiada również na inny typowy problem: dlaczego nie mogę używać zmiennych do rozpoznawania nazw połączeń usług/środowisk? Zasoby są autoryzowane przed rozpoczęciem działania etapu, dlatego zmienne na poziomie etapu i zadania nie są dostępne. Zmienne na poziomie potoku mogą być używane, ale tylko te zmienne jawnie uwzględnione w potoku. Same grupy zmiennych są zasobem podlegającym autoryzacji, dlatego ich dane również nie są dostępne podczas sprawdzania autoryzacji zasobów.

Żądanie agenta

Za każdym razem, gdy usługa Azure Pipelines musi uruchomić zadanie, poprosi o pulęagenta. (Zadania serwera są wyjątkiem, ponieważ są uruchamiane na samym serwerze usługi Azure Pipelines). Pule agentów hostowanych przez firmę Microsoft i samodzielnie działają nieco inaczej.

Żądania puli agentów hostowanych przez firmę Microsoft

Najpierw usługa sprawdza równoległe zadania organizacji. Sumuje wszystkie uruchomione zadania dla wszystkich agentów hostowanych przez firmę Microsoft i porównuje je z liczbą zakupionych zadań równoległych. Jeśli nie ma dostępnych gniazd równoległych, zadanie musi czekać na wolne miejsce.

Po udostępnieniu gniazda równoległego zadanie jest kierowane do żądanego typu agenta. Koncepcyjnie pula hostowana przez firmę Microsoft jest jedną gigantyczną, globalną pulą maszyn. (W rzeczywistości jest to wiele różnych pul fizycznych podzielonych według lokalizacji geograficznej i typu systemu operacyjnego). Na podstawie żądanej vmImage nazwy puli (w języku YAML) lub nazwy puli (w edytorze klasycznym) wybrano agenta.

Wybór puli

Wszyscy agenci w puli firmy Microsoft są nowi, nowi maszyny wirtualne, które wcześniej nie uruchamiały żadnych potoków. Po zakończeniu zadania maszyna wirtualna agenta zostanie odrzucona.

Żądania puli agentów hostowanych samodzielnie

Podobnie jak w przypadku puli hostowanej przez firmę Microsoft usługa najpierw sprawdza zadania równoległe organizacji. Sumuje wszystkie uruchomione zadania dla wszystkich własnych agentów i porównuje je z liczbą zakupionych zadań równoległych. Jeśli nie ma dostępnych gniazd równoległych, zadanie musi czekać na wolne miejsce.

Po udostępnieniu gniazda równoległego pula hostowana samodzielnie jest badana dla zgodnego agenta. Agenci hostowani samodzielnie oferują możliwości, które są ciągami wskazującymi, że określone oprogramowanie jest zainstalowane lub skonfigurowano ustawienia. Potok ma wymagania, które są możliwościami wymaganymi do uruchomienia zadania. Jeśli nie można odnaleźć bezpłatnego agenta, którego możliwości są zgodne z wymaganiami potoku, zadanie będzie nadal czekać. Jeśli w puli nie ma agentów, których możliwości odpowiadają wymaganiom, zadanie zakończy się niepowodzeniem.

Agenci hostowani samodzielnie są zwykle ponownie używane z uruchamiania do uruchomienia. W przypadku własnych agentów zadanie potoku może mieć skutki uboczne, takie jak rozgrzewanie pamięci podręcznych lub posiadanie większości zatwierdzeń dostępnych już w lokalnym repozytorium.

Przygotowanie do uruchomienia zadania

Po zaakceptowaniu zadania agent ma pewne prace przygotowawcze do wykonania. Agent pobiera (i buforuje następnego czasu) wszystkie zadania potrzebne do uruchomienia zadania. Tworzy przestrzeń roboczą na dysku do przechowywania kodu źródłowego, artefaktów i danych wyjściowych używanych w przebiegu. Następnie rozpoczyna uruchamianie kroków.

Uruchamianie każdego kroku

Kroki są uruchamiane sekwencyjnie, jeden po drugim. Przed rozpoczęciem kroku wszystkie poprzednie kroki muszą zostać zakończone (lub pominięte).

Uruchamianie każdego zadania

Kroki są implementowane przez zadania. Same zadania są implementowane jako skrypty Node.js lub programu PowerShell. System zadań kieruje dane wejściowe i wyjściowe do skryptów tworzenia kopii zapasowych. Udostępnia również niektóre typowe usługi, takie jak zmiana ścieżki systemowej i tworzenie nowych zmiennych potoku.

Każdy krok jest uruchamiany we własnym procesie, izolując go od środowiska pozostawionego przez poprzednie kroki. Ze względu na ten model procesu na krok zmienne środowiskowe nie są zachowywane między krokami. Jednak zadania i skrypty mają mechanizm komunikacji z agentem: polecenia rejestrowania. Gdy zadanie lub skrypt zapisuje polecenie rejestrowania w celu standaryzacji, agent podejmie niezależnie od żądanej akcji.

Istnieje polecenie agenta, aby utworzyć nowe zmienne potoku. Zmienne potoku zostaną automatycznie przekonwertowane na zmienne środowiskowe w następnym kroku. Aby ustawić nową zmienną myVar z wartością myValue, skrypt może wykonać następujące czynności:

echo '##vso[task.setVariable variable=myVar]myValue'

Write-Host "##vso[task.setVariable variable=myVar]myValue"

Raport i zbieranie wyników

Każdy krok może zgłaszać ostrzeżenia, błędy i błędy. Błędy i ostrzeżenia są zgłaszane na stronie podsumowania potoku, oznaczając zadanie jako "powodzenie z problemami". Błędy są również zgłaszane na stronie podsumowania, ale oznaczają zadanie jako "niepowodzenie". Krok jest niepowodzeniem, jeśli jawnie zgłasza błąd (przy użyciu ##vso polecenia) lub kończy skrypt z kodem zakończenia niezerowym.

Dzienniki i wyniki przepływają z agenta do usługi

Po uruchomieniu kroków agent stale wysyła wiersze wyjściowe do usługi. Dlatego możesz zobaczyć kanał informacyjny na żywo konsoli programu . Na końcu każdego kroku wszystkie dane wyjściowe z kroku są również przekazywane jako plik dziennika. Dzienniki można pobrać po zakończeniu potoku. Inne elementy, które agent może przekazać, obejmują artefakty i wyniki testów. Są one również dostępne po zakończeniu potoku.

Stan i warunki

Agent śledzi powodzenie lub niepowodzenie każdego kroku. W miarę powodzenia kroków z problemami lub niepowodzeniem stan zadania zostanie zaktualizowany. Zadanie zawsze odzwierciedla "najgorszy" wynik każdego z jego kroków: jeśli krok zakończy się niepowodzeniem, zadanie również zakończy się niepowodzeniem.

Przed uruchomieniem kroku agent sprawdzi warunek tego kroku, aby określić, czy ma zostać uruchomiony. Domyślnie krok będzie uruchamiany tylko wtedy, gdy stan zadania zakończył się pomyślnie lub zakończył się pomyślnie. Wiele zadań ma kroki oczyszczania, które muszą być uruchamiane bez względu na to, co się stało, dzięki czemu mogą określić warunek "always()". Kroki oczyszczania można również ustawić tak, aby uruchamiały się tylko po anulowaniu. Pomyślny krok oczyszczania nie może zapisać zadania przed niepowodzeniem; zadania nigdy nie mogą wrócić do powodzenia po wprowadzeniu błędu.

Limity czasu i rozłączenia

Każde zadanie ma limit czasu. Jeśli zadanie nie zostało ukończone w określonym czasie, serwer anuluje zadanie. Podejmie próbę zasygnalizowania zatrzymania agenta i oznaczy zadanie jako anulowane. Po stronie agenta oznacza to anulowanie wszystkich pozostałych kroków i przekazanie pozostałych wyników.

Zadania mają okres prolongaty znany jako limit czasu anulowania, w którym można ukończyć pracę anulowania. (Pamiętaj, że kroki można oznaczyć do uruchomienia nawet w przypadku anulowania). Po przekroczeniu limitu czasu i przekroczeniu limitu czasu anulowania, jeśli agent nie zgłosił, że praca została zatrzymana, serwer oznaczy zadanie jako niepowodzenie.

Ponieważ usługa Azure Pipelines dystrybuuje pracę do maszyn agentów, od czasu do czasu agenci mogą przestać odpowiadać na serwer. Może się to zdarzyć, jeśli maszyna hosta agenta zniknie (utrata zasilania, maszyna wirtualna wyłączona) lub jeśli wystąpi awaria sieci. Aby ułatwić wykrywanie tych warunków, agent wysyła raz na minutę komunikat pulsu, aby poinformować serwer, że nadal działa. Jeśli serwer nie otrzyma pulsu przez pięć kolejnych minut, zakłada, że agent nie wróci. Zadanie jest oznaczone jako niepowodzenie, informując użytkownika, że powinien ponowić próbę wykonania potoku.

Zarządzanie przebiegami za pośrednictwem interfejsu wiersza polecenia

Za pomocą interfejsu wiersza polecenia usługi Azure DevOps możesz wyświetlić listę przebiegów potoku w projekcie i wyświetlić szczegółowe informacje o określonym przebiegu. Tagi można również dodawać i usuwać w przebiegu potoku.

Wymagania wstępne

  • Musisz zainstalować rozszerzenie interfejsu wiersza polecenia usługi Azure DevOps zgodnie z opisem w temacie Wprowadzenie do interfejsu wiersza polecenia usługi Azure DevOps.
  • Zaloguj się do usługi Azure DevOps przy użyciu polecenia az login.
  • W przykładach w tym artykule ustaw domyślną organizację przy użyciu polecenia az devops configure --defaults organization=YourOrganizationURL.

Wyświetlanie listy przebiegów potoków

Wyświetl listę przebiegów potoku w projekcie za pomocą polecenia az pipelines run list . Aby rozpocząć pracę, zobacz Wprowadzenie do interfejsu wiersza polecenia usługi Azure DevOps.

az pipelines runs list [--branch]
                       [--org]
                       [--pipeline-ids]
                       [--project]
                       [--query-order {FinishTimeAsc, FinishTimeDesc, QueueTimeAsc, QueueTimeDesc, StartTimeAsc, StartTimeDesc}]
                       [--reason {all, batchedCI, buildCompletion, checkInShelveset, individualCI, manual, pullRequest, schedule, triggered, userCreated, validateShelveset}]
                       [--requested-for]
                       [--result {canceled, failed, none, partiallySucceeded, succeeded}]
                       [--status {all, cancelling, completed, inProgress, none, notStarted, postponed}]
                       [--tags]
                       [--top]

Parametry opcjonalne

  • branch: filtruj według kompilacji dla tej gałęzi.
  • org: Adres URL organizacji usługi Azure DevOps. Domyślną organizację można skonfigurować przy użyciu polecenia az devops configure -d organization=ORG_URL. Wymagane, jeśli nie zostało skonfigurowane jako domyślne lub odebrane przy użyciu polecenia git config. Przykład: --org https://dev.azure.com/MyOrganizationName/.
  • pipeline-ids: identyfikatory rozdzielone spacjami definicji, dla których mają być wyświetlone kompilacje.
  • projekt: nazwa lub identyfikator projektu. Domyślny projekt można skonfigurować przy użyciu polecenia az devops configure -d project=NAME_OR_ID. Wymagane, jeśli nie zostało skonfigurowane jako domyślne lub odebrane przy użyciu polecenia git config.
  • query-order: zdefiniuj kolejność uruchamiania potoku. Akceptowane wartości to FinishTimeAsc, FinishTimeDesc, QueueTimeAsc, QueueTimeDesc, StartTimeAsc i StartTimeDesc.
  • przyczyna: Tylko kompilacje listy z tego określonego powodu. Akceptowane wartości to batchedCI, buildCompletion, checkInShelveset, individualCI, manual, pullRequest, schedule, triggered, userCreated i validateShelveset.
  • requested-for: Ogranicz do kompilacji żądanych dla określonego użytkownika lub grupy.
  • result: Ogranicz do kompilacji z określonym wynikiem. Zaakceptowane wartości są anulowane, zakończone niepowodzeniem, brak, częściowoSucceeded i zakończone powodzeniem.
  • status: Ogranicz do kompilacji o określonym stanie. Akceptowane wartości to wszystkie, anulowanie, ukończenie, ruch przychodzący, brak, niestarted i odroczone.
  • tagi: ogranicz do kompilacji przy użyciu każdego z określonych tagów. Odstęp rozdzielony.
  • top: Maksymalna liczba kompilacji do listy.

Przykład

Poniższe polecenie zawiera listę pierwszych trzech przebiegów potoku, które mają stan ukończony i wynik powodzenia, i zwraca wynik w formacie tabeli.

az pipelines runs list --status completed --result succeeded --top 3 --output table

Run ID    Number      Status     Result     Pipeline ID    Pipeline Name               Source Branch    Queued Time                 Reason
--------  ----------  ---------  ---------  -------------  --------------------------  ---------------  --------------------------  ------
125       20200124.1  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 18:56:10.067588  manual
123       20200123.2  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 11:55:56.633450  manual
122       20200123.1  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 11:48:05.574742  manual

Pokaż szczegóły przebiegu potoku

Pokaż szczegóły uruchomienia potoku w projekcie za pomocą polecenia az pipelines run show . Aby rozpocząć pracę, zobacz Wprowadzenie do interfejsu wiersza polecenia usługi Azure DevOps.

az pipelines runs show --id
                       [--open]
                       [--org]
                       [--project]

Parametry

  • id: Wymagane. Identyfikator przebiegu potoku.
  • otwórz: Opcjonalnie. Otwiera stronę wyników kompilacji w przeglądarce internetowej.
  • org: Adres URL organizacji usługi Azure DevOps. Domyślną organizację można skonfigurować przy użyciu polecenia az devops configure -d organization=ORG_URL. Wymagane, jeśli nie zostało skonfigurowane jako domyślne lub odebrane przy użyciu polecenia git config. Przykład: --org https://dev.azure.com/MyOrganizationName/.
  • projekt: nazwa lub identyfikator projektu. Domyślny projekt można skonfigurować przy użyciu polecenia az devops configure -d project=NAME_OR_ID. Wymagane, jeśli nie zostało skonfigurowane jako domyślne lub odebrane przy użyciu polecenia git config.

Przykład

Poniższe polecenie pokazuje szczegóły przebiegu potoku o identyfikatorze 123 i zwraca wyniki w formacie tabeli. Spowoduje to również otwarcie przeglądarki internetowej na stronie wyników kompilacji.

az pipelines runs show --id 122 --open --output table

Run ID    Number      Status     Result     Pipeline ID    Pipeline Name               Source Branch    Queued Time                 Reason
--------  ----------  ---------  ---------  -------------  --------------------------  ---------------  --------------------------  --------
123       20200123.2  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 11:55:56.633450  manual

Dodawanie tagu do uruchomienia potoku

Dodaj tag do uruchomienia potoku w projekcie za pomocą polecenia az pipelines run tag add . Aby rozpocząć pracę, zobacz Wprowadzenie do interfejsu wiersza polecenia usługi Azure DevOps.

az pipelines runs tag add --run-id
                          --tags
                          [--org]
                          [--project]

Parametry

  • run-id: wymagane. Identyfikator przebiegu potoku.
  • tagi: wymagane. Tagi do dodania do przebiegu potoku (wartości rozdzielane przecinkami).
  • org: Adres URL organizacji usługi Azure DevOps. Domyślną organizację można skonfigurować przy użyciu polecenia az devops configure -d organization=ORG_URL. Wymagane, jeśli nie zostało skonfigurowane jako domyślne lub odebrane przy użyciu polecenia git config. Przykład: --org https://dev.azure.com/MyOrganizationName/.
  • projekt: nazwa lub identyfikator projektu. Domyślny projekt można skonfigurować przy użyciu polecenia az devops configure -d project=NAME_OR_ID. Wymagane, jeśli nie zostało skonfigurowane jako domyślne lub odebrane przy użyciu polecenia git config.

Przykład

Następujące polecenie dodaje tag YAML do uruchomienia potoku o identyfikatorze 123 i zwraca wynik w formacie JSON.

az pipelines runs tag add --run-id 123 --tags YAML --output json

[
  "YAML"
]

Wyświetlanie listy tagów przebiegu potoku

Wyświetl listę tagów przebiegu potoku w projekcie za pomocą polecenia az pipelines run tag list . Aby rozpocząć pracę, zobacz Wprowadzenie do interfejsu wiersza polecenia usługi Azure DevOps.

az pipelines runs tag list --run-id
                           [--org]
                           [--project]

Parametry

  • run-id: wymagane. Identyfikator przebiegu potoku.
  • org: Adres URL organizacji usługi Azure DevOps. Domyślną organizację można skonfigurować przy użyciu polecenia az devops configure -d organization=ORG_URL. Wymagane, jeśli nie zostało skonfigurowane jako domyślne lub odebrane przy użyciu polecenia git config. Przykład: --org https://dev.azure.com/MyOrganizationName/.
  • projekt: nazwa lub identyfikator projektu. Projekt domyślny można skonfigurować przy użyciu polecenia az devops configure -d project=NAME_OR_ID. Wymagane, jeśli wartość domyślna nie jest skonfigurowana lub wybrana przy użyciu polecenia git config.

Przykład

Następujące polecenie wyświetla listę tagów dla uruchomienia potoku z identyfikatorem 123 i zwraca wynik w formacie tabeli.

az pipelines runs tag list --run-id 123 --output table

Tags
------
YAML

Usuwanie tagu z uruchomienia potoku

Usuń tag z uruchomienia potoku w projekcie za pomocą polecenia az pipelines runs tag delete . Aby rozpocząć pracę, zobacz Rozpoczynanie pracy z interfejsem wiersza polecenia usługi Azure DevOps.

az pipelines runs tag delete --run-id
                             --tag
                             [--org]
                             [--project]

Parametry

  • run-id: wymagane. Identyfikator uruchomienia potoku.
  • tag: wymagane. Tag do usunięcia z uruchomienia potoku.
  • org: adres URL organizacji usługi Azure DevOps. Domyślną organizację można skonfigurować przy użyciu polecenia az devops configure -d organization=ORG_URL. Wymagane, jeśli wartość domyślna nie jest skonfigurowana lub wybrana przy użyciu polecenia git config. Przykład: --org https://dev.azure.com/MyOrganizationName/.
  • projekt: nazwa lub identyfikator projektu. Projekt domyślny można skonfigurować przy użyciu polecenia az devops configure -d project=NAME_OR_ID. Wymagane, jeśli wartość domyślna nie jest skonfigurowana lub wybrana przy użyciu polecenia git config.

Przykład

Następujące polecenie usuwa tag YAML z uruchomienia potoku o identyfikatorze 123.

az pipelines runs tag delete --run-id 123 --tag YAML