Ресурсы в конвейерах YAML

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

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

После определения ресурса его можно использовать в любом месте конвейера. Дополнительные сведения и примеры см. в определениях ресурсов.

resources:
  pipelines:
  - pipeline: resources1
    source: otherPipeline

steps:
- download: resources1
  artifact: artifact1.txt

Состояние ресурса можно использовать для автоматического активации конвейеров, задав trigger свойство в определении ресурса. Затем конвейер resources.triggeringAlias и resources.triggeringCategory переменные задаются в качестве имени ресурса и категории. Эти переменные пусты, если Build.Reason переменная не задана ResourceTrigger.

Ресурсы позволяют полностью отслеживать использование конвейера служб, включая версию, артефакты, связанные фиксации и рабочие элементы. Если вы подписаны на активацию событий в ресурсах, вы можете полностью автоматизировать рабочие процессы DevOps.

Примечание.

В этой статье рассматриваются ресурсы в конвейерах YAML. Сведения о ресурсах в классических конвейерах см. в разделе "Сведения о ресурсах для Azure Pipelines".

Авторизация ресурсов

Ресурсы должны быть авторизованы для использования в конвейерах. Владельцы ресурсов управляют пользователями и конвейерами, которые могут получить доступ к своим ресурсам. Существует несколько способов авторизации конвейера YAML для использования ресурсов.

• Используйте параметры администрирования ресурса, чтобы предоставить разрешения на доступ ко всем конвейерам. Например, вы можете управлять защищенными файлами и группами переменных на страницебиблиотеки конвейеров, а также пулы > и подключения служб в параметрах> проектаконвейеров. Эта авторизация удобна для ресурсов, которые не нужно ограничивать, например тестовые ресурсы.

• Убедитесь, что у вас есть по крайней мере роль пользователя в ролях безопасности пула агентов для проекта. Создаваемые конвейеры YAML автоматически авторизованы для использования ресурсов, где у вас есть роль пользователя .

• Если вы добавляете определение ресурса в конвейер YAML, но сборка завершается ошибкой, например Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use, убедитесь, что у вас есть по крайней мере роль пользователя в ресурсе. Затем можно выбрать параметр для авторизации ресурсов в неудачной сборке. После того как ресурс будет авторизован, вы можете начать новую сборку.

Проверки утверждения ресурсов

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

Настройка требуемого утверждения шаблона повышает безопасность, гарантируя, что ресурс используется только в определенных условиях. Дополнительные сведения см. в разделе "Использование шаблонов для безопасности".

Средство выбора версий вручную

Azure Pipelines оценивает версии по умолчанию для ресурсов на основе их определений ресурсов. Для запланированных запусков или ручных запусков, если вы не выбрали выполнение вручную, Azure Pipelines считает, что выполняется только успешно завершенная непрерывная интеграция (CI) для оценки версий ресурсов по умолчанию.

Средство выбора версий ресурсов вручную можно использовать для выбора различных версий ресурсов при запуске конвейера непрерывного развертывания YAML (CD). Средство выбора версий ресурса поддерживается для конвейера, сборки, репозитория, контейнера и пакетных ресурсов.

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

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

Чтобы использовать средство выбора версий ресурсов, выберите "Ресурсы " в области "Запуск конвейера ", выберите ресурс и выберите определенную версию из списка доступных версий. Для ресурсов, где вы не можете получить доступные версии, такие как пакеты GitHub, можно ввести нужную версию в текстовом поле.

Определения ресурсов

Ресурсы конвейера YAML могут быть следующими:

• Другие конвейеры
• сборки
• Контейнеры
• Пакеты
• Репозитории или
• Веб-перехватчики.

В следующих разделах приведены определения и примеры категорий ресурсов конвейера YAML. Полные сведения о схеме см. в определении ресурсов в справочнике по схеме YAML для Azure Pipelines.

Ресурс конвейеров

Ресурсы CI pipeline можно использовать в качестве триггеров для рабочих процессов CD. Вы также можете ссылаться на pipeline ресурсы из конвейера, чтобы скачать артефакты или использовать переменные ресурсов конвейера. Только Azure Pipelines могут использовать ресурс pipelines.

В определении pipelines ресурса:

• pipeline — это уникальное имя, используемое для ссылки на ресурсы конвейера.
• source — это имя конвейера, создающего артефакты конвейера.

Полные сведения о схеме см. в определении resources.pipelines.pipeline .

Примеры определений ресурсов конвейера

В следующем примере определения ресурсов используются артефакты из конвейера в том же проекте Azure DevOps.

resources:
  pipelines:
  - pipeline: SmartHotel-resource # identifier to use in pipeline resource variables
    source: SmartHotel-CI # name of the pipeline that produces the artifacts

Чтобы указать конвейер из другого проекта, добавьте project имя в определение ресурса. В следующем примере также используется branch для разрешения версии по умолчанию при активации конвейера вручную или по расписанию. Входные данные для ветки не могут содержать подстановочные символы.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    source: SmartHotel-CI
    branch: releases/M142

Оценка версий ресурсов

Azure Pipelines оценивает версии по умолчанию для ресурсов на основе их определений ресурсов. Версии артефактов ресурсов конвейера по умолчанию зависят от того, выполняется ли конвейер вручную или по расписанию, или триггеры в зависимости от результата выполнения ресурса.

Для выполнения вручную или запланированного конвейера значения versionbranchtags значений и свойств в pipeline определении ресурса определяют версии артефактов. Входные branch данные не могут содержать подстановочные знаки, а tags свойства используют AND оператор.

Для запланированных запусков или вручную, если вы не используете средство выбора версий, Azure Pipelines рассматривает только успешно завершенную непрерывную интеграцию (CI) при оценке версий ресурсов по умолчанию. Для выполнения вручную можно переопределить определенные версии с помощью средства выбора версий вручную.

В следующей таблице перечислены pipeline свойства определения ресурсов и указанные им версии артефактов.

Указанное свойство	Версия артефакта
version	Сборка с указанным номером выполнения
branch	Последняя сборка, запущенная в указанной ветви
tags	Последняя сборка со всеми указанными тегами
branch и tags	Последнее выполнение сборки в указанной ветви с указанными тегами
version и branch	Сборка с указанным номером выполнения и указанной ветвью
нет	Последняя сборка во всех ветвях

В следующем pipeline определении ресурсов используются branch свойства и tags свойства для оценки версии по умолчанию при планировании или запуске конвейера вручную. Версия myCIAlias артефактов — это последняя сборка main в ветви с Production тегами и PreProduction тегами.

resources:
  pipelines:
  - pipeline: myCIAlias
    project: Fabrikam
    source: Fabrikam-CI
    branch: main
    tags:
    - Production
    - PreProduction

Триггеры ресурсов конвейера

Для выполнения конвейера, который активируется в результате выполнения ресурса, trigger параметры свойств в определении ресурса определяют версии артефактов ресурсов по умолчанию. Чтобы использовать pipeline ресурс в качестве триггера для запуска текущего конвейера, необходимо задать trigger свойство. Если вы не включаете trigger свойство, запуски ресурсов не активируют текущие запуски конвейера.

Если конвейер активируется на trigger основе значения в pipeline определении ресурса, значения общего определения versionbranchресурса и tags свойства игнорируются. Свойства trigger определяют версии артефактов.

Внимание

При определении триггера ресурса конвейера:

• pipeline Если ресурс находится из того же репозитория, что и текущий конвейер, или selfтриггер находится в той же ветви и фиксирует событие триггера.
• pipeline Если ресурс отличается от текущего pipeline конвейера, активируется в ветви по умолчанию репозитория ресурсов.

В следующей таблице описывается, как trigger свойства влияют на поведение триггера.

Свойство Триггера	Поведение триггера
true	Активация возникает при успешном завершении выполнения конвейера ресурсов.
branches	Активация возникает, когда конвейер ресурсов успешно завершает выполнение в одной из include ветвей.
tags	Активация возникает, когда конвейер ресурсов успешно завершает выполнение, помеченное всеми указанными тегами.
stages	Активация возникает, когда конвейер ресурсов успешно запускает указанный stages.
branches, tags и stages	Активация возникает, когда успешный запуск конвейера ресурсов удовлетворяет всем условиям ветви, тега и этапа.

В следующем примере показано определение ресурсов конвейеров с простым trigger.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    source: SmartHotel-CI
    trigger: true

В следующем примере показан ресурс trigger конвейера с условиями для ветки.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
      - releases/*
      - resources.triggeringAlias

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

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Fabrikam-CI  
    trigger:    
      stages:
      - PreProduction
      - Production

В следующем примере используются tags фильтры для оценки версий по умолчанию и триггера. Теги trigger используют AND оператор. Набор tags определений ресурсов отличается от тегов, заданных в pipeline ветвях в репозитории Git.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Fabrikam-CI
    tags: 
    - Production 
    trigger:
      tags:
      - Production
      - Signed

Следующий конвейер выполняется каждый раз, когда задействован конвейер ресурсов:

• Выполняется в одной из releases ветвей или в main ветви.
• Помечен как и VerifiedSigned.
• Завершает и ProductionPreProduction этапы.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
        include:
        - releases/*
        - main
        exclude:
        - topic/*
      tags: 
      - Verified
      - Signed
      stages:
      - Production
      - PreProduction

Скачивание артефакта конвейера

Шаг download в конвейере YAML можно использовать для скачивания артефактов, связанных с текущим запуском или другим pipeline ресурсом.

Артефакты загружают автоматически только в заданиях развертывания. Все артефакты из текущего конвейера и все его pipeline ресурсы автоматически загружаются и доступны в начале каждого задания развертывания. Это поведение можно переопределить, задав downloadnoneили указав другой pipeline идентификатор ресурса.

В обычном задании сборки артефакты не загружают автоматически. Используйте download явно при необходимости.

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

Необязательное patterns свойство определяет шаблоны, представляющие файлы для скачивания. Полные сведения о схеме см. в определении steps.download .

- job: deploy_windows_x86_agent
  steps:
  - download: SmartHotel
    artifact: WebTier1
    patterns: '**/*.zip'

Артефакты из скачиваемого pipeline ресурса в $(PIPELINE. WORKSPACE)/<pipeline-identifier>/<artifact-identifier> folder. Дополнительные сведения см. в статье "Публикация и скачивание артефактов конвейера". Альтернативный способ скачивания артефактов конвейера см. в разделе "Скачать артефакты".

Переменные ресурса конвейера

Метаданные для ресурса конвейера доступны всем заданиям в каждом запуске в качестве предопределенных переменных. Эти переменные доступны вашему конвейеру только во время выполнения, поэтому их нельзя использовать в шаблонных выражениях, которые вычисляются во время компиляции конвейера.

Дополнительные сведения см. в разделе "Определение переменных " и метаданных ресурса конвейера в качестве предопределенных переменных.

В следующем примере возвращаются предопределенные значения переменной myresourcevars для ресурса конвейера.

resources:
  pipelines:
  - pipeline: myresourcevars
    source: mypipeline
    trigger: true 

steps:
- script: |
    echo $(resources.pipeline.myresourcevars.pipelineID)
    echo $(resources.pipeline.myresourcevars.runName)
    echo $(resources.pipeline.myresourcevars.runID)
    echo $(resources.pipeline.myresourcevars.runURI)
    echo $(resources.pipeline.myresourcevars.sourceBranch)
    echo $(resources.pipeline.myresourcevars.sourceCommit)
    echo $(resources.pipeline.myresourcevars.sourceProvider)
    echo $(resources.pipeline.myresourcevars.requestedFor)
    echo $(resources.pipeline.myresourcevars.requestedForID)

Создание ресурса

Если у вас есть система сборки CI, которая создает артефакты, можно использовать артефакты с builds ресурсами.

Категория builds расширяема. build Ресурс может быть из любой внешней системы CI, например Jenkins, TeamCity или CircleCI. Можно использовать builds для записи расширения для использования артефактов из службы сборки или создания нового типа службы.

build В определении version по умолчанию используется последняя успешная сборка. Если требуется, необходимо явно задать trigger . Полные сведения о схеме см. в определении resources.builds.build .

В следующем примере Jenkins — это тип ресурса.

resources:
  builds:
  - build: Spaceworkz
    type: Jenkins
    connection: MyJenkinsServer 
    source: SpaceworkzProj   # name of the Jenkins source project
    trigger: true

Внимание

Триггеры поддерживаются только для управляемого Jenkins, где Azure DevOps имеет возможность взаимодействовать с сервером Jenkins.

Задача downloadBuild

build Артефакты ресурсов не загружаются автоматически в задания и задания развертывания. Чтобы использовать артефакты из ресурса build в ваших заданиях, необходимо явно добавить задачу downloadBuild. Вы можете настроить поведение загрузки для каждого развертывания или задания.

Задача downloadBuild автоматически разрешает соответствующую задачу скачивания для типа ресурса, определяемого build средой выполнения. Артефакты из скачиваемого build ресурса в $(PIPELINE. WORKSPACE)/<build-identifier>/ folder.

В определении вы указываете downloadBuild ресурс для загрузки артефактов. Свойство artifact, которое является необязательным, определяет артефакты для скачивания. Если это не указано, все артефакты, связанные с скачиванием ресурсов.

Необязательное patterns свойство определяет минималистичный путь или список минималистичных путей для скачивания. Если пусто, все артефакты скачиваются. В следующем примере скачиваются только файлы *.zip .

- job: deploy_windows_x86_agent
  steps:
  - downloadBuild: Spaceworkz
    patterns: '**/*.zip'

Полные сведения о схеме см. в определении steps.downloadBuild .

Ресурс репозиториев

Используйте ключевое слово, чтобы сообщить системе repository о внешних репозиториях, если:

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

Например:

resources:
  repositories:
  - repository: common
    type: github
    name: Contoso/CommonTools
    endpoint: MyContosoServiceConnection

Полные сведения о схеме см. в определении resources.repositories.repository .

Типы ресурсов репозитория

Azure Pipelines поддерживает gitтипы, githubа githubenterpriseтакже bitbucket типы репозиториев.

• Тип git относится к репозиториям Azure Repos Git.
• Репозитории GitHub Enterprise требуют подключения службы GitHub Enterprise для авторизации.
• Bitbucket Cloud repos требует подключения к облачной службе Bitbucket для авторизации.

В следующей таблице описаны repository типы ресурсов:

Тип	Значение имени	Пример
git	Другой репозиторий в одном проекте или одной организации.	Тот же проект: name: otherRepo Другой проект в той же организации: name: otherProject/otherRepo.
github	Полное имя репозитория GitHub, включая пользователя или организацию.	name: myOrganization/otherRepo
githubenterprise	Полное имя репозитория GitHub Enterprise, включая пользователя или организацию.	name: myEnterpriseOrg/otherRepo
bitbucket	Полное имя репозитория Bitbucket Cloud, включая пользователя или организацию.	name: MyBitbucketOrg/otherRepo

Переменные ресурсов репозитория

Метаданные ресурса репозитория доступны всем заданиям во всех запусках в качестве переменных среды выполнения. Идентификатор <alias>repository из repository определения ресурса.

resources.repositories.<alias>.name
resources.repositories.<alias>.ref
resources.repositories.<alias>.type
resources.repositories.<alias>.id
resources.repositories.<alias>.url
resources.repositories.<alias>.version

В следующем примере имеется псевдоним common, поэтому вы обращаетесь к переменным ресурса репозитория с помощью resources.repositories.common.*.

resources:
  repositories:
    - repository: common
      type: git
      ref: main
      name: Repo

variables:
  ref: $[ resources.repositories.common.ref ]
  name: $[ resources.repositories.common.name ]
  id: $[ resources.repositories.common.id ]
  type: $[ resources.repositories.common.type ]
  url: $[ resources.repositories.common.url ]
  version: $[ resources.repositories.common.version ]

steps:
- bash: |
    echo "name = $(name)"
    echo "ref = $(ref)"
    echo "id = $(id)"
    echo "type = $(type)"
    echo "url = $(url)"
    echo "version = $(version)"

Ключевое слово "checkout" для репозиториев

Репозитории из ресурса repository не синхронизируются автоматически в ваших задачах. Ключевое checkout слово можно использовать для получения репозитория, определенного в ресурсе repository . Для получения дополнительной информации см. Обзор нескольких репозиториев в вашем конвейере. Полные сведения о схеме см. в определении steps.checkout .

Ресурс контейнеров

Ресурсы можно использовать для использования containers образов контейнеров в конвейерах CI/CD. container Ресурс может быть общедоступным или частным реестром Docker или экземпляром реестра контейнеров Azure.

Вы можете использовать универсальный образ ресурса контейнера в рамках заданий или использовать его в заданиях контейнеров. Если конвейеру требуется поддержка одной или нескольких служб, необходимо также создать и подключиться к контейнерам служб. Тома можно использовать для совместного использования данных между службами.

Если вам нужно использовать образы из реестра Docker, можно определить универсальный ресурс контейнера без использования ключевого type слова. Например:

resources:         
  containers:
  - container: smartHotel 
    endpoint: myDockerRegistry
    image: smartHotelApp 

Полные сведения о схеме см. в определении resources.container.container .

Примечание.

Синтаксис enabled: 'true' для включения триггеров контейнера для тегов изображений отличается от синтаксиса для других триггеров ресурсов. Не забудьте использовать правильный синтаксис для определенных ресурсов.

тип ресурса Реестр контейнеров Azure

Чтобы воспользоваться образами из Реестра контейнеров Azure, используйте тип ресурса контейнера первого класса acr. Этот тип ресурса можно использовать в заданиях и включить автоматические триггеры конвейера.

Для использования триггеров автоматического конвейера требуется разрешение участника реестра контейнеров Azure или владельца . Для получения дополнительной информации см. раздел Роли и разрешения в Реестре контейнеров Azure.

Чтобы использовать ресурс типа acr, необходимо указать значения azureSubscription, resourceGroup и repository для реестра контейнеров Azure. Например:

resources:         
  containers:
  - container: petStore      
    type: acr  
    azureSubscription: ContosoConnection
    resourceGroup: ContosoGroup
    registry: petStoreRegistry
    repository: myPets
    trigger: 
      tags:
        include: 
        - production* 

Примечание.

Оценка триггера выполняется только в ветви по умолчанию. Убедитесь, что задать правильную основную ветвь или объединить файл YAML в текущую основную ветвь. Дополнительные сведения об изменении ветви конвейера по умолчанию см. в разделе "Ветвь конвейера по умолчанию".

Переменные ресурсов контейнера

После определения контейнера в качестве ресурса метаданные образа контейнера передаются в конвейер в виде переменных. Информация, такая как образ, реестр и детали подключения, доступна во всех заданиях, связанных с задачами развертывания контейнеров.

Переменные ресурсов контейнеров работают с Docker и Azure Container Registry. Нельзя использовать переменные ресурсов контейнера для контейнеров локальных образов. Переменная location применяется только к типу acr ресурса контейнера.

В следующем примере имеется подключение службы Azure Resource Manager с именем arm-connection. Дополнительные сведения см. в реестрах контейнеров Azure, репозиториях и образах.

resources:
  containers:
  - container: mycontainer
    type: acr
    azureSubscription: arm-connection
    resourceGroup: rg-storage-eastus
    registry: mycontainerregistry
    repository: hello-world
    trigger:
      tags:
      - latest

steps:
- script: echo |
    echo $(resources.container.mycontainer.type)
    echo $(resources.container.mycontainer.registry)
    echo $(resources.container.mycontainer.repository)
    echo $(resources.container.mycontainer.tag)
    echo $(resources.container.mycontainer.digest)
    echo $(resources.container.mycontainer.URI)
    echo $(resources.container.mycontainer.location)

Ресурс пакетов

Пакеты NuGet и npm GitHub можно использовать в качестве ресурсов в конвейерах YAML. Чтобы включить автоматические триггеры конвейера при выпуске новой версии пакета, задайте trigger для свойства значение true.

При определении package ресурсов укажите пакет <repository>\<name> в свойстве name и задайте пакет type как NuGet или npm. Чтобы использовать пакеты GitHub, используйте проверку подлинности на основе ПАТ и создайте подключение службы GitHub, использующее PAT.

Полные сведения о схеме см. в определении resources.packages.package .

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

В следующем примере показано подключение к сервису GitHub с именем pat-contoso, связанное с npm-пакетом GitHub под названием contoso. Дополнительные сведения см. в статье о пакетах GitHub.

resources:
  packages:
    - package: contoso
      type: npm
      connection: pat-contoso
      name: myname/contoso 
      version: 7.130.88 
      trigger: true

steps:
- getPackage: contoso

Ресурс веб-перехватчиков

Примечание.

Веб-перехватчики, выпущенные в Azure DevOps Server 2020.1.

Вы можете использовать конвейер Azure Pipelines, контейнер, сборку и пакеты ресурсов для использования артефактов и автоматизации триггеров, но их нельзя использовать для базирования развертываний во внешних событиях или службах. Веб-перехватчики автоматизируют рабочий процесс на основе внешних событий веб-перехватчика, которые не поддерживают ресурсы Azure Pipelines первого класса. Вы можете подписаться на внешние события через веб-перехватчики и использовать события для активации конвейеров.

Ресурс webhooks в конвейерах YAML позволяет интегрировать конвейеры с внешними службами, такими как GitHub, GitHub Enterprise, Nexus и Artifactory для автоматизации рабочих процессов. Для локальных служб, в которых Azure DevOps не имеет видимости процесса, вы можете настроить веб-перехватчики в службе для автоматического активации конвейеров.

Чтобы подписаться на событие веб-перехватчика, необходимо определить webhook ресурс в конвейере и указать входящее подключение службы веб-перехватчика. Полные сведения о схеме см. в определении resources.webhooks.webhook .

Полезные данные JSON можно использовать в качестве переменных в заданиях с помощью формата ${{ parameters.<WebhookAlias>.<JSONPath>}}. Следующий пример определяет и вызывает ресурс веб-перехватчика:

resources:
  webhooks:
    - webhook: myWebhookResource
      connection: myWebHookConnection

steps:  
- script: echo ${{ parameters.myWebHookResource.resource.message.title }}

Фильтры в ресурсе веб-перехватчика можно определить на основе полезных данных JSON для настройки триггеров для каждого конвейера. Всякий раз, когда подключение к входящей службе веб-перехватчика получает событие веб-перехватчика, новые триггеры запуска для всех конвейеров, подписанных на это событие веб-перехватчика.

В следующем примере используются фильтры веб-перехватчика.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          
      connection: MyWebhookConnection    
      filters:
        - path: repositoryName      
          value: maven-releases     
        - path: action
          value: CREATED

steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

Конфигурация триггера веб-перехватчика

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

• URL-адрес запроса: https://dev.azure.com/<org_name>/_apis/public/distributedtask/webhooks/<webhook_connection_name>?api-version=6.0-preview
• Секрет (необязательно): если необходимо защитить полезные данные JSON, укажите значение секрета.

Вподключениях службы "Параметры проекта Azure DevOps >>Service" создается новое подключение к входящей службе веб-перехватчика. Например, можно определить следующие сведения для типа подключения службы GitHub:

• Имя веб-перехватчика: имя подключения веб-перехватчика, созданное во внешней службе.
• Секрет (необязательно): хэш полезных данных HMAC-SHA1 для проверки входящего запроса. Если при создании веб-перехватчика вы использовали секрет, необходимо указать тот же секрет.
• Заголовок HTTP (необязательно): заголовок HTTP в запросе, который содержит HMAC-SHA1 хэш-значение полезных данных для проверки запроса. Например, заголовок запроса GitHub имеет значение X-Hub-Signature.

Чтобы активировать конвейер с помощью веб-перехватчика, выполните POST запрос https://dev.azure.com/<org_name>/_apis/public/distributedtask/webhooks/<webhook_connection_name>?api-version=6.0-preview. Эта конечная точка общедоступна и не требует авторизации. Запрос должен иметь текст, аналогичный следующему примеру:

{
    "resource": {
        "message": {
            "title": "Hello, world!",
            "subtitle": "I'm using WebHooks!"
        }
    }
}

Примечание.

Доступ к данным из текста запроса веб-перехватчика может привести к неправильному YAML. Например, шаг - script: echo ${{ parameters.WebHook.resource.message }} конвейера извлекает все сообщение JSON, которое создает недопустимый YAML. Любой конвейер, активируемый с помощью этого веб-перехватчика, не запускается, так как созданный YAML недопустим.

Возможность трассировки

Azure Pipelines обеспечивает полную трассировку любого ресурса, потребляемого на уровне конвейера или задания на развертывание. Azure Pipelines отображает следующие сведения для каждого запуска конвейера, использующего ресурсы:

• Если ресурс активировал конвейер, то это тот же самый ресурс, который активировал конвейер.
• Версии ресурсов и используемые артефакты.
• Коммиты, связанные с каждым ресурсом.
• Рабочие элементы, связанные с каждым ресурсом.

Связанные сведения о конвейере CD для конвейеров CI

Чтобы обеспечить сквозную трассировку, можно отслеживать, какие конвейеры CD используют определенный конвейер CI через pipelines ресурс. Если другие конвейеры потребляли конвейер CI, вы увидите вкладку "Связанные конвейеры " в представлении "Запуск ". В представлении показаны все запуски конвейера CD YAML, использовавшие ваш конвейер CI и артефакты из него.

Трассируемость среды

После развертывания конвейера в среде вы увидите список ресурсов, которые он использовал, и связанные с ними фиксации и рабочие элементы.

Вопросы и ответы

Когда следует использовать ресурсы пайплайнов, функцию быстрой загрузки или задачу «Скачать артефакты пайплайнов»?

Использование ресурса pipelines — это способ использования артефактов из CI-конвейера и настройки автоматических триггеров. Ресурс позволяет полностью контролировать процесс, предоставляя информацию об используемой версии, артефактах, фиксациях и рабочих элементах. При определении ресурса конвейера связанные артефакты автоматически загружаются в заданиях развертывания.

С помощью download ярлыка можно скачать артефакты в заданиях сборки или переопределить поведение загрузки в заданиях развертывания. Дополнительные сведения см. в определении steps.download .

Задача Download Pipeline Artifacts не обеспечивает возможность трассировки или триггеры, но иногда имеет смысл использовать эту задачу напрямую. Например, у вас может быть задача скрипта, хранящаяся в другом шаблоне и требующая скачивания артефактов из сборки. Или, возможно, вы не захотите добавлять ресурс конвейера в шаблон. Чтобы избежать зависимостей, вы можете использовать задачу "Загрузка артефактов конвейера" для передачи всей информации о сборке в задачу.

Как активировать запуск потока, когда мой образ Docker Hub обновляется?

Триггер ресурса контейнера недоступен для конвейеров Docker Hub для YAML, поэтому необходимо настроить классический конвейер выпуска.

1. Создайте новое подключение к службе Docker Hub.
2. Создайте классический конвейер выпуска и добавьте артефакт Docker Hub. Задайте подключение службы и выберите пространство имен, репозиторий, версию и псевдоним источника.
3. Выберите триггер и переключите триггер непрерывного развертывания, чтобы включить. Каждый push Docker, выполняемый в выбранный репозиторий, создает релиз.
4. Создайте новый этап и задание. Добавьте две задачи: вход в Docker и Bash.
   • Задача Docker имеет действие login и выполняет вход на Docker Hub.
   • Задача Bash выполняется docker pull <hub-user>/<repo-name>[:<tag>].

Как проверить и диагностировать проблемы вебхука?

1. Создайте подключение к службе.

2. Укажите подключение к службе и задайте название веб-перехватчика в разделе webhooks.

   resources:
     webhooks:
       - webhook: MyWebhookTriggerAlias
         connection: MyServiceConnection
   

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

4. Выполните API вызов, используя корректный JSON в теле запроса POST к https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>. Если вы получите ответ с кодом состояния 200, это означает, что ваш веб-перехватчик готов к обработке в вашем конвейере.

Если вы получаете ответ на код состояния 500 с ошибкойCannot find webhook for the given webHookId ..., код может находиться в ветви, которая не ветвь по умолчанию. Чтобы устранить эту проблему, выполните следующие действия:

1. Выберите "Изменить" на странице конвейера.
2. В меню "Дополнительные действия" выберите "Триггеры".
3. Выберите вкладку YAML и выберите " Получить источники".
4. В разделе "Ветвь по умолчанию для ручных и запланированных сборок", обновите свою функциональную ветвь.
5. Нажмите Сохранить и поместить в очередь.
6. После успешного выполнения этого конвейера выполните вызов API, передавая допустимый JSON в теле запроса на POST. Теперь вы должны получить ответ на код состояния 200.

Почему не работал триггер ресурса?

Триггеры ресурсов могут не выполняться, так как:

• Источник предоставленного подключения к службе недопустим.
• Триггер не настроен или в триггере возникают синтаксические ошибки.
• Условия триггера не совпадают с заданными.

Чтобы узнать, почему триггеры конвейера не удалось выполнить, выберите пункт меню "Проблемы триггера " на странице определения конвейера. Проблемы с триггером недоступны для ресурсов репозитория.

На странице проблем триггера сообщения об ошибках и предупреждениях описывают, почему триггер не сработал.

Связанный контент

• Сведения о ресурсах для Azure Pipelines
• Определение переменных
• Добавление и использование групп переменных
• Создание среды и выбор ее в качестве целевой
• Использование редактора конвейера YAML
• Справочник по схемам YAML