Активация одного конвейера после другого

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

Крупные продукты имеют несколько компонентов, которые зависят друг от друга. Эти компоненты часто создаются независимо. При изменении вышестоящего компонента (например, библиотеки) подчиненные зависимости должны быть перестроены и обновлены.

В таких ситуациях добавьте триггер конвейера для запуска конвейера после успешного завершения запуска конвейера.

Настройка триггеров ресурсов конвейера

Чтобы активировать конвейер после завершения другого конвейера, настройте триггер ресурса конвейера.

В следующем примере настраивается триггер ресурса конвейера, чтобы конвейер с именем app-ci запускался после завершения всякого выполнения конвейера security-lib-ci.

В этом примере есть два следующих конвейера.

• security-lib-ci . Сначала выполняется этот конвейер.

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

• app-ci . Эта платформа имеет триггер ресурса платформы, который настраивает платформу app-ci для автоматического выполнения каждый раз, когда выполнение платформы 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 указывает имя ресурса конвейера. Используйте метку, определенную здесь, при обращении к ресурсу конвейера из других частей конвейера, например при использовании переменных ресурсов конвейера или скачивании артефактов.
• source: security-lib-ci указывает имя конвейера, на который ссылается этот ресурс конвейера. Имя трубопровода можно получить в нескольких местах на портале Azure DevOps, например, на домашней странице Pipelines. По умолчанию конвейеры именуются в честь репозитория, содержащего конвейер. Для обновления имени конвейера см. раздел Параметры конвейера. Если конвейер содержится в папке, добавьте имя папки, включая начальные \, например \security pipelines\security-lib-ci.
• project: FabrikamProject. Если конвейер активации находится в другом проекте Azure DevOps, необходимо указать имя проекта. Это свойство является необязательным, если исходный конвейер и триггерный конвейер находятся в одном проекте. Если указать это значение и конвейер не активируется, см. заметку в конце этого раздела.
• trigger: true. Используйте этот синтаксис для активации конвейера при завершении любой версии исходного конвейера. Чтобы узнать, какие версии исходного конвейера, завершив выполнение, будут запускать операцию, ознакомьтесь со следующими разделами в этой статье. При указании фильтров запуск исходного конвейера должен соответствовать всем фильтрам, чтобы активировать выполнение.

Если триггерный конвейер и активируемый конвейер используют один и тот же репозиторий, оба конвейера будут выполняться с тем же коммитом, когда один активирует другой. Это полезно, если первый конвейер создает код, а второй конвейер проверяет его. Однако если два конвейера используют разные репозитории, триггерный конвейер будет использовать версию кода в ветви, указанной параметром Default branch for manual and scheduled builds, как описано в рекомендациях Branch для триггеров завершения конвейера.

Настройка триггеров завершения конвейера не поддерживается в шаблонах YAML. Вы по-прежнему можете определить ресурсы конвейера в шаблонах.

Фильтры ветви

При необходимости можно указать ветви для включения или исключения при настройке триггера. При указании фильтров ветвей новый конвейер активируется каждый раз, когда завершился успешный запуск исходного конвейера, соответствующий заданным фильтрам ветвей. В следующем примере потоковая линия app-ci запускается, если security-lib-ci завершается в любой ветви releases/*, за исключением releases/old*.

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

Чтобы активировать дочерний конвейер для разных ветвей, для которых активируется родительский объект, включите все фильтры ветвей, для которых активируется родительский объект. В следующем примере конвейер app-ci запускается, если security-lib-ci завершится на любой ветви releases/* или на главной ветви, за исключением releases/old*.

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

Фильтры тегов

Свойство tags фильтров trigger определяет, какие события завершения конвейера могут активировать ваш конвейер. Если триггерный конвейер соответствует всем тегам в списке tags, конвейер запускается.

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

Фильтры этапов

Вы можете запустить свой конвейер, когда один или несколько этапов инициирующего конвейера завершены, используя фильтр stages. Если вы предоставляете несколько этапов, триггерный конвейер запускается после завершения всех перечисленных этапов.

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. 

Аспекты ветви

Триггеры завершения конвейера используют ветвь по умолчанию для ручной и запланированной сборки, чтобы определить версию ветвей конвейера YAML, чтобы определить, следует ли запускать конвейер в результате завершения другого конвейера. По умолчанию этот параметр указывает на ветвь по умолчанию репозитория.

После завершения конвейера среда выполнения Azure DevOps оценивает фильтры ветвей триггера ресурса конвейера любых конвейеров с триггерами завершения конвейера, ссылающимися на завершенный конвейер. Конвейер может иметь несколько версий в разных ветвях, поэтому среда выполнения оценивает фильтры ветвей в версии конвейера в ветви, указанной параметром Default branch for manual and scheduled builds. Если имеется совпадение, конвейер запускается, но версия конвейера, который выполняется, может находиться в другой ветви в зависимости от того, находится ли триггерный конвейер в том же репозитории, что и завершенный конвейер.

• Если два конвейера находятся в разных репозиториях, запускается активная версия конвейера в ветви, указанной Default branch for manual and scheduled builds.
• Если два конвейера находятся в одном репозитории, запущенная версия конвейера в той же ветви, что и конвейер триггера (с использованием версии конвейера из этой ветви во время выполнения условия триггера), даже если эта ветвь отличается от Default branch for manual and scheduled builds, и даже если у этой версии нет фильтров ветвей, соответствующих ветви завершенного конвейера. Это связано с тем, что фильтры ветви из ветви Default branch for manual and scheduled builds используются для определения того, должен ли конвейер выполняться, а не фильтры ветвей в версии, которая находится в завершенной ветви конвейера.

Если триггеры завершения конвейера не запускаются, проверьте значение ветви по умолчанию для ручной и запланированной сборки для триггерного конвейера. Фильтры ветвей в версии конвейера этой ветви используются для определения того, запускает ли триггер завершения конвейера новый запуск. По умолчанию Default branch for manual and scheduled builds назначается в качестве основной ветви репозитория, но вы можете изменить ее после создания потока данных.

Типичный сценарий, в котором триггер завершения конвейера не запускается при создании новой ветви, фильтры триггера завершения конвейера изменяются, чтобы включить эту новую ветвь, но когда первый конвейер завершается в ветви, которая соответствует новым фильтрам ветвей, второй конвейер не запускается. Это происходит, если фильтры ветвей в версии пайплайна в ветви Default branch for manual and scheduled builds не соответствуют новой ветви. Чтобы устранить эту проблему триггера, у вас есть следующие два варианта.

• Обновите фильтры ветвей в потоке в ветви Default branch for manual and scheduled builds таким образом, чтобы они соответствовали новой ветви.
• Обновите ветку по умолчанию для ручной и запланированной сборки на ветку, содержащую версию конвейера с фильтрами веток, соответствующими новой ветке.

Объединение типов триггеров

При указании триггеров CI и триггеров конвейера в конвейере можно ожидать, что новые запуски будут выполняться каждый раз, когда совершается отправка, соответствующая фильтрам триггера CI, и когда выполнение исходного конвейера завершается, соответствуя фильтрам триггера завершения конвейера.

Например, рассмотрим два конвейера с именем A и B, которые находятся в одном репозитории, оба имеют триггеры CI, а B имеет триггер завершения конвейера, настроенный для завершения Aконвейера. При внесении изменений в репозиторий:

• Запускается новый запуск A на основе триггера CI.
• В то же время запускается новый цикл B на основе триггера CI. Этот запуск использует результаты предыдущего запуска конвейера A.
• После завершения A запускается еще один запуск Bна основе триггера завершения конвейера в B.

Чтобы предотвратить активацию двух запусков B в этом примере, необходимо отключить триггер CI (trigger: none) или триггер конвейера (pr: none).