Wyzwalanie jednego potoku po drugim

  • 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ć potok po pomyślnym zakończeniu potoku wyzwalającego.

Uwaga

Wcześniej możesz 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. Zalecaną metodą jest określenie wyzwalaczy potoku bezpośrednio w pliku YAML. Wyzwalacze uzupełniania kompilacji zdefiniowane w edytorze klasycznym mają różne wady, które zostały rozwiązane w wyzwalaczach potoku. Na przykład nie ma możliwości wyzwolenia potoku w tej samej gałęzi co potok wyzwalający przy użyciu wyzwalaczy kompilacji.

Konfigurowanie wyzwalaczy 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 działa po zakończeniu dowolnego uruchomienia potoku security-lib-ci .

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

  • security-lib-ci — Ten potok 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 app-ci potok 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 określa nazwę potoku, do których 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 potoki są nazwane po repozytorium, które zawiera potok. Aby zaktualizować nazwę potoku, zobacz Ustawienia potoku. Jeśli potok jest zawarty w folderze, dołącz nazwę folderu, w tym wiodącą \wartość , 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 wyzwolić 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. Jest to przydatne, jeśli pierwszy potok kompiluje kod i drugi potok testuje go. Jeśli jednak dwa potoki używają różnych repozytoriów, wyzwalany potok będzie używać wersji kodu w gałęzi określonej przez ustawienie, zgodnie z opisem Default branch for manual and scheduled builds w temacie Zagadnienia dotyczące gałęzi wyzwalaczy ukończenia potoku.

Uwaga

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 wartość zamiast na 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ż potok docelowy, możesz zaktualizować gałąź domyślną, aby uwzględnić refs/heads ją, 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 uzupełniania potoku nie jest obsługiwane w szablonach YAML. Nadal można definiować zasoby potoku 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 potok zostanie wyzwolony za każdym razem, gdy przebieg potoku źródłowego zostanie pomyślnie ukończony, który jest zgodny z filtrami gałęzi. W poniższym przykładzie potok jest uruchamiany, app-ci jeśli security-lib-ci element zostanie ukończony w dowolnej releases/* gałęzi, 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 jest uruchamiany, app-ci jeśli security-lib-ci element zostanie ukończony w dowolnej releases/* gałęzi lub gałęzi głównej, 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*

Uwaga

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

Filtry tagów

Właściwość tagstrigger filtrów, które zdarzenia uzupełniania potoku mogą wyzwalać potok. Jeśli potok wyzwalający jest zgodny ze wszystkimi tagami na tags liście, 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

Uwaga

Zasób potoku tags ma również właściwość . Właściwość tags zasobu potoku służy do określania przebiegu potoku w celu pobrania artefaktów, gdy potok zostanie wyzwolony ręcznie lub przez zaplanowany wyzwalacz. Aby uzyskać więcej informacji, zobacz Zasoby: potoki i Ocena wersji artefaktu.

Filtry etapu

Uwaga

Filtry etapów dla wyzwalaczy zasobów potoku wymagają usługi Azure DevOps Server 2020 Update 1 lub nowszej.

Potok można wyzwolić po zakończeniu co najmniej jednego etapu potoku wyzwalania przy użyciu 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łniania potoku używają domyślnej gałęzi dla ustawienia ręcznych i zaplanowanych kompilacji , aby określić, która wersja gałęzi filtrów gałęzi potoku YAML ma zostać obliczona podczas określania, czy uruchamiać 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 Default branch for manual and scheduled builds ustawienie. 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 potoki znajdują się w różnych repozytoriach, wyzwalana wersja potoku w gałęzi określonej przez Default branch for manual and scheduled builds jest uruchamiana.
  • Jeśli dwa potoki znajdują się w tym samym repozytorium, wyzwolona wersja potoku w tej samej gałęzi co potok wyzwalający jest uruchamiany (przy użyciu wersji potoku z tej gałęzi w momencie spełnienia warunku wyzwalacza), nawet jeśli ta gałąź jest inna niż Default branch for manual and scheduled builds, a nawet jeśli ta wersja nie ma filtrów gałęzi pasujących do gałęzi ukończonego potoku. Jest to spowodowane tym, że filtry gałęzi z Default branch for manual and scheduled builds gałęzi są używane do określania, czy potok powinien działać, a nie filtrów gałęzi w wersji, która znajduje się w ukończonej gałęzi potoku.

Jeśli wyzwalacze ukończenia potoku nie wydają się wyzwalać, sprawdź wartość domyślnej gałęzi dla ustawienia ręcznej i zaplanowanej kompilacji dla wyzwalanego potoku. Filtry gałęzi w wersji potoku tej gałęzi są używane do określania, czy wyzwalacz uzupełniania potoku inicjuje uruchomienie potoku. 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 uzupełniania potoku nie jest uruchamiany po utworzeniu nowej gałęzi, filtry gałęzi wyzwalacza ukończenia potoku są modyfikowane w celu uwzględnienia tej nowej gałęzi, ale po zakończeniu pierwszego potoku w gałęzi zgodnej z nowymi filtrami gałęzi drugi potok nie jest wyzwalany. Dzieje się tak, jeśli filtry gałęzi w wersji potoku w Default branch for manual and scheduled builds gałęzi 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 potoku w Default branch for manual and scheduled builds gałęzi, aby były zgodne z nową gałęzią.
  • Zaktualizuj ustawienie Domyślna gałąź dla ręcznej i zaplanowanej kompilacji do gałęzi, która ma wersję potoku, z filtrami gałęzi, które pasują do nowej 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, oba mają wyzwalacze ciągłej integracji i B mają wyzwalacz ukończenia potoku skonfigurowany do ukończenia potoku A. Jeśli wykonasz wypchnięcie do repozytorium:

  • Uruchomiono nowy przebieg na podstawie wyzwalacza ciągłej A integracji.
  • W tym samym czasie jest uruchamiany nowy przebieg na podstawie wyzwalacza ciągłej B integracji. Ten przebieg używa artefaktów z poprzedniego uruchomienia potoku A.
  • Po A zakończeniu wyzwala kolejny przebieg Belementu na podstawie wyzwalacza ukończenia potoku w pliku B.

Aby zapobiec wyzwalaniu dwóch przebiegów w tym przykładzie, należy wyłączyć wyzwalacz ciągłej B integracji (trigger: none) lub wyzwalacz potoku (pr: none).