Udostępnij za pośrednictwem

Uruchamianie jednej pipeliny po drugiej

  • Artykuł

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

Duże produkty mają kilka składników zależnych od siebie. Te składniki są często tworzone niezależnie. Gdy składnik nadrzędny (na przykład biblioteka) ulegnie zmianie, zależności podrzędne muszą zostać ponownie skompilowane i ponownie wycofane.

W takich sytuacjach dodaj wyzwalacz potoku, aby uruchomić go po pomyślnym zakończeniu uruchamiania potoku przez potok wyzwalający.

Notatka

Wcześniej można było przejść do klasycznego edytora dla potoku YAML i skonfigurować wyzwalacze uzupełniania kompilacji w interfejsie użytkownika. Mimo że ten model nadal działa, nie jest już zalecany. Zalecanym podejściem jest ustawienie wyzwalaczy potoku bezpośrednio w pliku YAML. Wyzwalacze zakończenia budowy zdefiniowane w edytorze klasycznym mają różne wady, które zostały uwzględnione w wyzwalaczach ciągu. Na przykład nie ma możliwości wyzwolenia potoku w tej samej gałęzi co potok wyzwalający przy użyciu wyzwalaczy kompilacji.

Wyzwalacze zdefiniowane przy użyciu interfejsu ustawień potoku mają pierwszeństwo przed wyzwalaczami YAML. Aby usunąć zaplanowane wyzwalacze UI z potoku YAML, zobacz ustawienia UI zastępują zaplanowane wyzwalacze YAML.

Skonfiguruj wyzwalacze zasobów potoku

Aby wyzwolić potok po zakończeniu innego potoku, skonfiguruj wyzwalacz zasobu potoku .

W poniższym przykładzie skonfigurowano wyzwalacz zasobu potoku tak, aby potok o nazwie app-ci był uruchamiany po zakończeniu dowolnego uruchomienia potoku security-lib-ci.

Ten przykład obejmuje dwa następujące potoki.

  • security-lib-ci — ten pipeline jest uruchamiany jako pierwszy.

    # security-lib-ci YAML pipeline
steps:
- bash: echo "The security-lib-ci pipeline runs first"

  • app-ci — ten potok ma wyzwalacz zasobu potoku, który konfiguruje potok app-ci do automatycznego uruchamiania przy każdym zakończeniu przebiegu potoku security-lib-ci.

    # app-ci YAML pipeline
# We are setting up a pipeline resource that references the security-lib-ci
# pipeline and setting up a pipeline completion trigger so that our app-ci
# pipeline runs when a run of the security-lib-ci pipeline completes
resources:
  pipelines:
  - pipeline: securitylib # Name of the pipeline resource.
    source: security-lib-ci # The name of the pipeline referenced by this pipeline resource.
    project: FabrikamProject # Required only if the source pipeline is in another project
    trigger: true # Run app-ci pipeline when any run of security-lib-ci completes

steps:
- bash: echo "app-ci runs after security-lib-ci completes"
  • - pipeline: securitylib określa nazwę zasobu potoku. Użyj etykiety zdefiniowanej tutaj podczas odwoływania się do zasobu potoku z innych części potoku, na przykład podczas korzystania ze zmiennych zasobów potoku lub pobierania artefaktów.
  • source: security-lib-ci wskazuje nazwę potoku, do którego odwołuje się ten zasób potoku. Nazwę potoku można pobrać z portalu Usługi Azure DevOps w kilku miejscach, takich jak strona docelowa Pipelines. Domyślnie pipeline'y otrzymują nazwę od repozytorium, które je zawiera. Aby zaktualizować nazwę pipeline'u, zobacz Ustawienia pipeline'u. Jeśli potok znajduje się w folderze, dołącz nazwę folderu, w tym wiodącą \, na przykład \security pipelines\security-lib-ci.
  • project: FabrikamProject — jeśli potok wyzwalania znajduje się w innym projekcie usługi Azure DevOps, musisz określić nazwę projektu. Ta właściwość jest opcjonalna, jeśli zarówno potok źródłowy, jak i potok wyzwalany znajdują się w tym samym projekcie. Jeśli określisz tę wartość, a potok nie jest wyzwalany, zobacz notatkę na końcu tej sekcji.
  • trigger: true — Użyj tej składni, aby wyzwolić potok po zakończeniu dowolnej wersji potoku źródłowego. Zapoznaj się z poniższymi sekcjami w tym artykule, aby dowiedzieć się, jak filtrować, które wersje ukończenia potoku źródłowego będą wyzwalać przebieg. Po określeniu filtrów uruchomienie potoku źródłowego musi być zgodne ze wszystkimi filtrami, aby uruchomić przebieg.

Jeśli potok wyzwalający i wyzwolony potok używają tego samego repozytorium, oba potoki będą uruchamiane przy użyciu tego samego zatwierdzenia, gdy jeden wyzwala drugie. Przydaje się to, jeśli pierwszy pipeline kompiluje kod, a drugi go testuje. Jeśli jednak dwa potoki używają różnych repozytoriów, wyzwalany potok użyje wersji kodu w gałęzi określonej przez ustawienie Default branch for manual and scheduled builds, zgodnie z opisem w temacie Rozważania dotyczące gałęzi dla wyzwalaczy zakończenia potoku.

Notatka

W niektórych scenariuszach domyślna gałąź kompilacji ręcznych i zaplanowanych kompilacji nie zawiera prefiksu refs/heads. Na przykład gałąź domyślna może być ustawiona na main zamiast refs/heads/main. W tym scenariuszu wyzwalacz z innego projektu nie działa. Jeśli wystąpią problemy podczas ustawiania project wartości innej niż docelowy potok, możesz zaktualizować gałąź domyślną tak, aby zawierała refs/heads, zmieniając jej wartość na inną gałąź, a następnie zmieniając ją z powrotem na gałąź domyślną, której chcesz użyć.

Konfigurowanie wyzwalaczy zakończenia potoku nie jest obsługiwane w szablonach YAML. Nadal można definiować zasoby pipeline'u w szablonach.

Filtry gałęzi

Opcjonalnie można określić gałęzie do uwzględnienia lub wykluczenia podczas konfigurowania wyzwalacza. Jeśli określisz filtry gałęzi, nowy pipeline zostanie wyzwolony za każdym razem, gdy przebieg źródłowego pipeline'u, który spełnia filtry gałęzi, zostanie pomyślnie zakończony. W poniższym przykładzie pipeline app-ci jest uruchamiany, jeśli security-lib-ci zostanie ukończony na dowolnej gałęzi releases/*, z wyjątkiem releases/old*.

# app-ci YAML pipeline
resources:
  pipelines:
  - pipeline: securitylib
    source: security-lib-ci
    trigger: 
      branches:
        include: 
        - releases/*
        exclude:
        - releases/old*

Aby wyzwolić potok podrzędny dla różnych gałęzi, dla których jest wyzwalany element nadrzędny, uwzględnij wszystkie filtry gałęzi, dla których jest wyzwalany element nadrzędny. W poniższym przykładzie potok app-ci jest uruchamiany, jeśli security-lib-ci zostanie ukończony w dowolnej gałęzi releases/* lub w głównej gałęzi, z wyjątkiem releases/old*.

# app-ci YAML pipeline
resources:
  pipelines:
  - pipeline: securitylib
    source: security-lib-ci
    trigger: 
      branches:
        include: 
        - releases/*
        - main
        exclude:
        - releases/old*

Notatka

Jeśli filtry gałęzi nie działają, spróbuj użyć prefiksu refs/heads/. Na przykład użyj refs/heads/releases/old*zamiast releases/old*.

Filtry tagów

Właściwość tags w filtrach trigger określa, które zdarzenia zakończenia potoku mogą wyzwalać potok. Jeśli potok wyzwalający jest zgodny ze wszystkimi tagami na liście tags, potok zostanie uruchomiony.

resources:
  pipelines:
  - pipeline: MyCIAlias
    source: Farbrikam-CI
    trigger:
      tags:        # This filter is used for triggering the pipeline run
      - Production # Tags are AND'ed
      - Signed

Nota

Zasób potoku ma również właściwość tags. Właściwość tags zasobu potoku służy do określenia, z którego przebiegu potoku pobrać artefakty, gdy potok jest uruchamiany ręcznie lub przez zaplanowany wyzwalacz. Aby uzyskać więcej informacji, zobacz Zasoby: potoki oraz Ocena wersji artefaktów.

Filtry etapu

Możesz wyzwolić potok, gdy jeden lub więcej etapów potoku wyzwalającego zakończy się, używając filtru stages. Jeśli podasz wiele etapów, wyzwalany potok zostanie uruchomiony po zakończeniu wszystkich wymienionych etapów.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    source: Farbrikam-CI  
    trigger:    
      stages:         # This stage filter is used when evaluating conditions for 
      - PreProduction # triggering your pipeline. On successful completion of all the stages
      - Production    # provided, your pipeline will be triggered.

Zagadnienia dotyczące gałęzi

Wyzwalacze uzupełnienia potoku używają ustawienia domyślnego gałęzi dla ręcznych i zaplanowanych kompilacji, aby określić, którą wersję filtrów gałęzi potoku YAML należy ocenić podczas decydowania, czy uruchomić potok w wyniku ukończenia innego potoku. Domyślnie to ustawienie wskazuje domyślną gałąź repozytorium.

Po zakończeniu potoku środowisko uruchomieniowe usługi Azure DevOps ocenia filtry gałęzi wyzwalacza zasobu potoku dla wszystkich potoków z wyzwalaczami ukończenia potoku odwołującymi się do ukończonego potoku. Potok może mieć wiele wersji w różnych gałęziach, więc środowisko uruchomieniowe ocenia filtry gałęzi w wersji potoku w gałęzi określonej przez ustawienie Default branch for manual and scheduled builds. Jeśli istnieje dopasowanie, potok jest uruchamiany, ale wersja potoku, który działa, może znajdować się w innej gałęzi w zależności od tego, czy wyzwalany potok znajduje się w tym samym repozytorium co ukończony potok.

  • Jeśli dwa pipeline'y znajdują się w różnych repozytoriach, zostanie uruchomiona wersja pipeline'u uruchomiona przez wyzwalacz w gałęzi określonej przez Default branch for manual and scheduled builds.
  • Jeśli dwa potoki znajdują się w tym samym repozytorium, wyzwolona wersja potoku w tej samej gałęzi, co potok wyzwalający, jest uruchamiana (korzystając z wersji potoku z tej gałęzi w momencie spełnienia warunku wyzwalania), nawet jeśli ta gałąź jest inna niż Default branch for manual and scheduled builds, a nawet jeśli ta wersja nie posiada filtrów gałęzi zgodnych z gałęzią ukończonego potoku. Jest to spowodowane tym, że filtry gałęzi z gałęzi Default branch for manual and scheduled builds są używane do określenia, czy potok powinien zostać uruchomiony, a nie filtry gałęzi w wersji, która znajduje się w ukończonej gałęzi potoku.

Jeśli wyzwalacze ukończenia potoku nie działają prawidłowo, sprawdź wartość gałęzi domyślnej dla ręcznych i zaplanowanych kompilacji oraz ustawienie w wyzwalanym potoku. Filtry gałęzi w wersji potoku tej gałęzi są używane do określenia, czy wyzwalacz zakończenia potoku inicjuje jego uruchomienie. Domyślnie Default branch for manual and scheduled builds jest ustawiona na domyślną gałąź repozytorium, ale można ją zmienić po utworzeniu potoku.

Typowy scenariusz, w którym wyzwalacz ukończenia potoku nie zostaje uruchomiony, ma miejsce po utworzeniu nowej gałęzi, gdy filtry gałęzi wyzwalacza ukończenia potoku zostają zmodyfikowane, aby uwzględnić tę nową gałąź. Jednak po ukończeniu pierwszego potoku w gałęzi, która pasuje do nowych filtrów gałęzi, drugi potok nie zostaje wyzwolony. Dzieje się tak, jeśli filtry gałęzi w wersji potoku w gałęzi Default branch for manual and scheduled builds nie są zgodne z nową gałęzią. Aby rozwiązać ten problem z wyzwalaczem, masz następujące dwie opcje.

  • Zaktualizuj filtry gałęzi w przebiegu w gałęzi Default branch for manual and scheduled builds, aby były zgodne z nową gałęzią.
  • Zaktualizuj ustawienie gałęzi domyślnej dla ręcznych i zaplanowanych kompilacji na gałąź, która zawiera wersję potoku z filtrami gałęzi zgodnymi z nową gałęzią.

Łączenie typów wyzwalaczy

Po określeniu zarówno wyzwalaczy ciągłej integracji, jak i wyzwalaczy potoku w potoku można oczekiwać uruchomienia nowych przebiegów za każdym razem, gdy wypchnięcie jest zgodne z filtrami wyzwalacza ciągłej integracji, a uruchomienie potoku źródłowego jest wykonywane zgodnie z filtrami wyzwalacza ukończenia potoku.

Rozważmy na przykład dwa potoki o nazwie A i B, które znajdują się w tym samym repozytorium; oboje mają wyzwalacze CI, a B ma wyzwalacz ukończenia skonfigurowany dla zakończenia potoku A. Jeśli wykonasz wysłanie do repozytorium:

  • Uruchomiono nowy przebieg A na podstawie wyzwalacza CI.
  • W tym samym czasie, bazując na wyzwalaczu ciągłej integracji, rozpoczynana jest nowa sesja B. Ten przebieg używa artefaktów z poprzedniego uruchomienia potoku A.
  • Gdy A się zakończy, inicjuje to kolejny przebieg Bna podstawie wyzwalacza zakończenia procesu w B.

Aby zapobiec wyzwalaniu dwóch uruchomień B w tym przykładzie, należy wyłączyć jego wyzwalacz CI (trigger: none) lub wyzwalacz potoku (pr: none).