Активация одного конвейера за другим

  • Статья

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

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

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

Примечание.

Ранее вы могли перейти к классическому редактору для конвейера YAML и настроить триггеры завершения сборки в пользовательском интерфейсе. Хотя эта модель по-прежнему работает, она больше не рекомендуется. Рекомендуемый подход — указать триггеры конвейера непосредственно в файле YAML. Триггеры завершения сборки, как определено в классическом редакторе, имеют различные недостатки, которые теперь устранены в триггерах конвейера. Например, невозможно активировать конвейер в той же ветви, что и триггер конвейер с помощью триггеров завершения сборки.

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

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

Следующий пример настраивает триггер ресурса конвейера таким образом, чтобы конвейер с именем 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 для триггеров завершения конвейера.

Примечание.

В некоторых сценариях ветвь по умолчанию для сборок вручную и запланированных сборок не включает refs/heads префикс. Например, для ветвь по умолчанию может быть задано значение mainrefs/heads/mainвместо . В этом сценарии триггер из другого проекта не работает. При возникновении проблем при установке project значения, отличного от целевого конвейера, можно обновить ветвь по умолчанию, чтобы включить refs/heads его, изменив его значение в другую ветвь, а затем изменив его обратно на ветвь по умолчанию, которую вы хотите использовать.

Настройка триггеров завершения конвейера не поддерживается в шаблонах 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 если выполняется в любой releases/* ветви или основной ветви, за исключением releases/old*security-lib-ci .

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

Примечание.

Если фильтры ветви не работают, попробуйте использовать префикс refs/heads/. Например, используйте refs/heads/releases/old* вместо releases/old*.

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

Примечание.

Для поддержки фильтра тегов для ресурсов конвейера требуется Azure DevOps Server 2020 с обновлением 1 или более поздней версии.

Свойство tagstrigger фильтров, которые могут активировать события завершения конвейера. Если триггерный конвейер соответствует всем тегам в списке 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

Примечание.

Ресурс конвейера также имеет tags свойство. Свойство tags ресурса конвейера используется для определения запуска конвейера для получения артефактов, когда конвейер активируется вручную или запланированным триггером. Дополнительные сведения см. в разделе "Ресурсы": конвейеры и оценка версии артефакта.

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

Конвейер можно активировать, когда один или несколько этапов триггерного конвейера завершены с помощью 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 ветви не соответствуют новой ветви. Чтобы устранить эту проблему триггера, у вас есть следующие два варианта.

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

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

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

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

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