Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
В этой статье рассматриваются ресурсы для конвейеров YAML. Ресурс — это всё, что используется конвейером и находится вне его. После определения ресурса его можно использовать в любом месте конвейера.
Ресурсы обеспечивают полную трассируемость для служб, которые использует ваш конвейер, включая версию, артефакты, связанные коммиты и рабочие элементы. Вы можете полностью автоматизировать рабочие процессы DevOps, подписавшись на триггерные события на ваших ресурсах.
Схема ресурсов
Ресурсы на языке YAML представляют собой источники конвейеров, сборок, репозиториев, контейнеров, пакетов и веб-перехватчиков. Полные сведения о схеме см. в определении ресурсов в справочнике по схеме YAML для Azure Pipelines.
Когда ресурс активирует конвейер, будут заданы следующие переменные:
resources.triggeringAlias
resources.triggeringCategory
Переменная Build.Reason
должна быть ResourceTrigger
для получения этих значений. Значения пусты, если ресурс не инициировал выполнение конвейера.
Определение ресурсов пайплайнов
Если у вас есть конвейер, который создает артефакты, можно использовать артефакты, определив pipelines
ресурс. Только Azure Pipelines могут использовать ресурс pipelines
. Триггеры для рабочих процессов непрерывного развертывания (CD) можно установить в конвейерном ресурсе.
В определении ресурса pipeline
это уникальное значение, которое вы можете использовать для ссылки на ресурс конвейера в дальнейшем в вашем конвейере.
source
— это название конвейера, который создал артефакт. Чтобы узнать полную информацию о схеме, посмотрите определение resources.pipelines.pipeline.
Вы используете метку, определенную pipeline
, чтобы ссылаться на ресурс конвейера из других частей вашего конвейера, например, при использовании переменных ресурса конвейера или скачивании артефактов. Альтернативный способ скачивания артефактов конвейера см. в разделе "Скачать артефакты".
Внимание
При определении триггера ресурса конвейера:
-
pipeline
Если ресурс из того же репозитория, что и текущий конвейер, илиself
, срабатывание следует той же ветви и коммиту, на которых возникает событие. - Если ресурс конвейера находится в другом репозитории
pipeline
, текущий конвейер активируется на ветке по умолчанию репозитория ресурсов.
Примеры определений ресурсов конвейера
В следующем примере используются артефакты из конвейера в рамках одного проекта.
resources:
pipelines:
- pipeline: SmartHotel-resource # identifier to use in pipeline resource variables
source: SmartHotel-CI # name of the pipeline that produces the artifacts
Чтобы использовать конвейер из другого проекта, укажите имя проекта и имя источника. В следующем примере используется branch
для разрешения версии по умолчанию, когда конвейер активируется вручную или запланирован. Входные данные для ветки не могут содержать подстановочные символы.
resources:
pipelines:
- pipeline: SmartHotel
project: DevOpsProject
source: SmartHotel-CI
branch: releases/M142
В следующем примере показан ресурс конвейера с простым триггером.
resources:
pipelines:
- pipeline: SmartHotel
project: DevOpsProject
source: SmartHotel-CI
trigger: true
В следующем примере показан ресурс trigger
конвейера с условиями для ветки.
resources:
pipelines:
- pipeline: SmartHotel
project: DevOpsProject
source: SmartHotel-CI
trigger:
branches:
- releases/*
- resources.triggeringAlias
В следующем примере используются stages
фильтры для оценки условий триггера для конвейеров CD. Оператор AND
используется на этапах. При успешном завершении всех указанных этапов конвейер CD активируется.
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
trigger:
stages:
- PreProduction
- Production
В следующем примере используются tags
фильтры для оценки версий по умолчанию и триггеров. Теги используют AND
оператор.
Элементы tags
устанавливаются в конвейере непрерывной интеграции (CI) или непрерывной доставки (CD). Эти теги отличаются от тегов, заданных в ветвях в репозитории Git.
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
tags:
- Production
trigger:
tags:
- Production
- Signed
Оценка версий артефактов конвейеров
Версия артефакта в конвейере ресурсов зависит от способа запуска этого конвейера.
Ручной или запланированный триггер
Если запуск конвейера активируется вручную или планируется, значения свойств version
, branch
, и tags
определяют версию артефакта. Входное branch
значение не может иметь подстановочные знаки. Свойства tags
используют AND
оператор.
Указанные свойства | Версия артефакта |
---|---|
version |
Артефакты сборки с указанным номером запуска |
branch |
Артефакты из последней сборки в указанной ветке. |
tags список |
Артефакты из последней сборки с указанными тегами |
список branch и tags |
Артефакты из последней сборки, выполненной на указанной ветке, которая имеет все указанные теги. |
version и branch |
Артефакты сборки с указанным номером запуска и указанной веткой. |
нет | Артефакты из последней сборки по всем веткам |
В следующем pipeline
определении ресурсов используются свойства branch
и tags
для определения версии по умолчанию при запуске конвейера вручную или по расписанию. При ручном запуске конвейера версия артефактов конвейера MyCIAlias
соответствует последней сборке, выполненной на ветви main
, которая содержит теги Production
и PrepProduction
.
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
branch: main
tags:
- Production
- PreProduction
Триггер завершения конвейера ресурсов
Когда конвейер запускается вследствие завершения одного из конвейеров ресурсов, версия артефактов — это версия конвейера, запускающего процесс. Значения свойств version
, branch
и tags
игнорируются.
Указанные триггеры | Результат |
---|---|
branches |
Новый запуск конвейера запускается всякий раз, когда ресурсный конвейер успешно завершает выполнение на одной из include ветвей. |
tags |
Новый запуск конвейера активируется всякий раз, когда конвейер ресурсов успешно завершает выполнение, помеченное всеми указанными тегами. |
stages |
Новый запуск конвейера активируется каждый раз, когда конвейер ресурсов успешно выполняет указанный stages . |
branches , tags и stages |
Новый запуск конвейера инициируется всякий раз, когда запуск конвейера ресурса удовлетворяет всем условиям ветвей, тегов и этапов. |
trigger: true |
Запуск нового конвейера происходит всякий раз, когда конвейер ресурсов успешно завершает выполнение. |
Ничего | Новый запуск конвейера не инициируется, когда конвейер ресурсов успешно завершает выполнение. |
Следующий конвейер выполняется каждый раз, когда задействован конвейер ресурсов:
- Выполняется в одной из
releases
ветвей или вmain
ветке - Помечен тегами
Verified
иSigned
- Завершает этапы
Production
иPreProduction
resources:
pipelines:
- pipeline: SmartHotel
project: DevOpsProject
source: SmartHotel-CI
trigger:
branches:
include:
- releases/*
- main
exclude:
- topic/*
tags:
- Verified
- Signed
stages:
- Production
- PreProduction
Скачивание артефакта конвейера
Шаг download
загружает артефакты, связанные с текущим запуском или с другим ресурсом в рамках конвейера.
Все артефакты из текущего конвейера и все его pipeline
ресурсы автоматически скачиваются и становятся доступными в начале каждого задания развертывания. Это поведение можно переопределить, задав download
none
или указав другой идентификатор ресурса конвейера.
Артефакты стандартных задач не загружаются автоматически. Используйте download
явно при необходимости.
Артефакты из pipeline
ресурса загружаются в папку $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier>. Дополнительные сведения см. в статье "Публикация и скачивание артефактов конвейера".
Необязательное artifact
свойство задает имена артефактов. Если это не указано, скачиваются все доступные артефакты. Необязательное patterns
свойство определяет шаблоны, представляющие файлы для включения. Полные сведения о схеме см. в определении steps.download.
- job: deploy_windows_x86_agent
steps:
- download: SmartHotel
artifact: WebTier1
patterns: '**/*.zip'
Переменные ресурса конвейера
В каждом запуске метаданные для ресурса конвейера доступны для всех заданий в качестве предопределенных переменных. Эти переменные доступны вашему конвейеру только во время выполнения, поэтому их нельзя использовать в шаблонных выражениях, которые вычисляются во время компиляции конвейера.
Дополнительные сведения см. в разделе Метаданные ресурса конвейера в виде предопределенных переменных. Дополнительные сведения о синтаксисе переменных см. в разделе "Определение переменных".
В следующем примере возвращаются предопределенные значения переменной 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
ресурсы.
build
Ресурс может быть из любой внешней системы CI, например Jenkins, TeamCity или CircleCI.
Категория builds
расширяема. Вы можете написать расширение для использования артефактов из службы сборки и ввести новый тип службы в составе builds
.
build
В определении version
по умолчанию используется последняя успешная сборка. Параметр trigger
не включен по умолчанию и должен быть явно задан. Для получения полной информации о схеме см. раздел resources.builds.build definition.
В следующем примере Jenkins является ресурсом type
.
resources:
builds:
- build: Spaceworkz
type: Jenkins
connection: MyJenkinsServer
source: SpaceworkzProj # name of the Jenkins source project
trigger: true
Внимание
Триггеры поддерживаются только для управляемого Jenkins, где Azure DevOps имеет возможность взаимодействовать с сервером Jenkins.
Задача downloadBuild
build
Артефакты ресурсов не загружаются автоматически в заданиях/deploy-jobs. Чтобы использовать артефакты из ресурса build
в ваших заданиях, необходимо явно добавить задачу 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 для авторизации.
Тип | Значение имени | Пример |
---|---|---|
type: git |
Другой репозиторий в том же проекте или той же организации. | Тот же проект: name: otherRepo Другой проект в той же организации: name: otherProject/otherRepo |
type: github |
Полное имя репозитория GitHub, включая пользователя или организацию. | name: Microsoft/vscode |
type: githubenterprise |
Полное имя репозитория GitHub Enterprise, включая пользователя или организацию. | name: Microsoft/vscode |
type: bitbucket |
Полное имя репозитория Bitbucket Cloud, включая пользователя или организацию. | name: MyBitbucket/vscode |
Переменные ресурсов репозитория
В каждом запуске следующие метаданные ресурса репозитория доступны всем заданиям в виде переменных среды выполнения. Это <Alias>
идентификатор, который вы предоставляете ресурсу репозитория.
resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.url
В следующем примере есть ресурс репозитория с псевдонимом 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 ]
steps:
- bash: |
echo "name = $(name)"
echo "ref = $(ref)"
echo "id = $(id)"
echo "type = $(type)"
echo "url = $(url)"
В каждом запуске следующие метаданные ресурса репозитория доступны всем заданиям в виде переменных среды выполнения. Это <Alias>
идентификатор, который вы предоставляете ресурсу репозитория.
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.
Для получения дополнительной информации см. Обзор нескольких репозиториев в вашем конвейере.
Определение ресурсов контейнеров
Если вам нужно использовать образы контейнеров в составе конвейеров CI/CD, можно использовать containers
ресурсы.
container
Ресурс может быть общедоступным или частным реестром Docker или экземпляром реестра контейнеров Azure.
Вы можете использовать универсальный образ ресурса контейнера в составе задания или использовать ресурс для контейнерных заданий. Если конвейеру требуется поддержка одной или нескольких служб, необходимо создать и подключиться к контейнерам служб. Тома можно использовать для обмена данными между службами.
Если вам нужно использовать образы из реестра Docker в рамках конвейера, можно определить универсальный ресурс контейнера. Не требуется ключевое слово type
. Например:
resources:
containers:
- container: smartHotel
endpoint: myDockerRegistry
image: smartHotelApp
Полные сведения о схеме см. в определении resources.containers.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
ресурсов укажите репозиторий< или> имя< пакета >в свойстве 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
pool:
vmImage: 'ubuntu-latest'
steps:
- getPackage: contoso
Определение ресурсов вебхуков
Примечание.
Вебхуки были выпущены в версии Azure DevOps Server 2020.1.
Вы можете использовать артефакты и активировать автоматические триггеры с помощью ресурсов конвейера, контейнера, сборки и пакетов. Однако эти ресурсы нельзя использовать для автоматизации развертываний на основе внешних событий или служб.
Ресурс webhooks
в конвейерах YAML позволяет интегрировать конвейеры с внешними службами, такими как GitHub, GitHub Enterprise, Nexus и Artifactory для автоматизации рабочих процессов. Вы можете подписаться на любые внешние события через веб-перехватчики и использовать события для активации конвейеров.
Вебхуки автоматизируют ваш рабочий процесс на основе любых внешних событий вебхуков, не поддерживаемых первоклассными ресурсами, такими как конвейеры, сборки, контейнеры или пакеты. Кроме того, для локальных служб, где Azure DevOps не может отслеживать процесс, вы можете настроить веб-перехватчики и автоматически запустить конвейеры.
Чтобы подписаться на событие веб-перехватчика, необходимо определить ресурс веб-перехватчика в конвейере и подключить его к входящему сервису веб-перехватчика. Кроме того, можно определить дополнительные фильтры в ресурсе веб-перехватчика на основе данных в формате JSON для настройки триггеров для каждого конвейера.
Всякий раз, когда сервис входящего веб-перехватчика получает событие веб-перехватчика, новый запуск инициируется для всех конвейеров, подписанных на событие веб-перехватчика. Полезные данные из JSON-запроса можно использовать в заданиях в качестве переменных с помощью формата ${{ parameters.<WebhookAlias>.<JSONPath>}}
.
Полную информацию о схеме см. в определении resources.webhooks.webhook.
В следующем примере определяется ресурс веб-хука:
resources:
webhooks:
- webhook: WebHook
connection: IncomingWH
steps:
- script: echo ${{ parameters.WebHook.resource.message.title }}
Триггеры веб-перехватчика
Чтобы настроить триггеры веб-перехватчика, сначала создайте веб-перехватчик на вашем внешнем сервисе, указав следующие сведения:
-
URL-адрес запроса:
https://dev.azure.com/<Azure DevOps organization>/_apis/public/distributedtask/webhooks/<webhook name>?api-version=6.0-preview
- Секрет (необязательно): если необходимо защитить полезные данные JSON, укажите значение секрета.
Затем вы создадите новое подключение для входящего вебхука. Для этого типа подключения службы вы определите следующие сведения:
- Имя вебхука: То же, что и у вебхука, созданного во внешнем сервисе.
- Секрет (дополнительно): используется для проверки 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 оказался некорректным.
В следующем фрагменте кода показан другой пример, использующий фильтры веб-хука.
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}}
Инструмент ручного выбора версий для ресурсов
При ручном запуске конвейера YAML CD Azure Pipelines автоматически вычисляет версии по умолчанию для ресурсов, определенных в конвейере, на основе предоставленных входных данных. Однако Azure Pipelines рассматривает только успешно завершенные запуски CI при оценке версии по умолчанию для запланированных триггеров или если вы не выберете версию вручную.
Вы можете использовать средство выбора версий ресурсов, чтобы вручную выбрать другую версию при создании запуска. Средство выбора версий ресурса поддерживается для конвейера, сборки, репозитория, контейнера и пакетных ресурсов.
Для ресурсов конвейера можно просмотреть все доступные запуски во всех ветвях, выполнить поиск по номеру конвейера или ветви и выбрать выполнение, которое выполнено успешно, завершилось сбоем или выполняется. Эта гибкость гарантирует, что вы можете запустить конвейер CD, если вы уверены, что выполнение создало все необходимые артефакты. Вам не нужно ждать завершения запуска CI или повторно запускать его из-за сбоя, не связанного с этапом.
Чтобы использовать средство выбора версий ресурсов, в области "Запуск конвейера " выберите "Ресурсы", а затем выберите ресурс и выберите определенную версию из списка доступных версий.
Для ресурсов, где вы не можете получить доступные версии, такие как пакеты GitHub, средство выбора версий предоставляет текстовое поле, чтобы ввести версию для выбора запуска.
Авторизация ресурсов в конвейерах YAML
Ресурсы должны быть авторизованы, прежде чем их можно будет использовать в конвейерах. Владельцы ресурсов управляют пользователями и конвейерами, которые могут получить доступ к своим ресурсам. Существует несколько способов авторизации конвейера 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 отображает следующие сведения для каждого запуска конвейера:
- Если ресурс активировал конвейер, то это тот же самый ресурс, который активировал конвейер.
- Версия ресурса и используемые артефакты.
- Коммиты, связанные с каждым ресурсом.
- Рабочие элементы, связанные с каждым ресурсом.
Трассируемость среды
При каждом развертывании конвейера в среде можно просмотреть список используемых ресурсов. В представлении содержатся ресурсы, используемые в рамках выполнения заданий по развертыванию, а также связанные с ними фиксации и рабочие элементы.
Информация о связанных потоках CD в потоках CI
Чтобы обеспечить сквозную отслеживаемость, можно отслеживать, какие конвейеры CD потребляют определенный конвейер CI через ресурс pipelines
. Если другие конвейеры используют конвейер CI, вы увидите вкладку «Связанные конвейеры» в представлении «Запуск». В представлении показаны все запуски конвейера CD YAML, использовавшие ваш конвейер CI и артефакты из него.
Проблемы с триггером ресурсов
Триггеры ресурсов могут не выполняться, так как:
- Источник предоставленного подключения к службе недопустим, в триггере возникают синтаксические ошибки или триггер не настроен.
- Условия триггера не совпадают с заданными.
Чтобы узнать, почему триггеры конвейера не удалось выполнить, выберите пункт меню "Проблемы триггера " на странице определения конвейера. Проблемы с триггерами доступны только для нерепозитарных ресурсов.
На странице проблем триггера сообщения об ошибках и предупреждениях описывают, почему триггер не сработал.
Вопросы и ответы
Когда следует использовать ресурсы пайплайнов, функцию быстрой загрузки или задачу «Скачать артефакты пайплайнов»?
Использование ресурса pipelines
— это способ использования артефактов из CI-конвейера и настройки автоматических триггеров. Ресурс позволяет полностью контролировать процесс, предоставляя информацию об используемой версии, артефактах, фиксациях и рабочих элементах. При определении ресурса конвейера связанные артефакты автоматически загружаются в заданиях развертывания.
С помощью download
ярлыка можно скачать артефакты в заданиях сборки или переопределить поведение загрузки в заданиях развертывания. Дополнительные сведения см. в определении steps.download.
Задача Download Pipeline Artifacts не обеспечивает возможность трассировки или триггеры, но иногда имеет смысл использовать эту задачу напрямую. Например, у вас может быть задача скрипта, хранящаяся в другом шаблоне и требующая скачивания артефактов из сборки. Или, возможно, вы не захотите добавлять ресурс конвейера в шаблон. Чтобы избежать зависимостей, вы можете использовать задачу "Загрузка артефактов конвейера" для передачи всей информации о сборке в задачу.
Как активировать запуск потока, когда мой образ Docker Hub обновляется?
Триггер ресурса контейнера недоступен для конвейеров Docker Hub для YAML, поэтому необходимо настроить классический конвейер выпуска.
- Создайте новое подключение к службе Docker Hub.
- Создайте классический конвейер выпуска и добавьте артефакт Docker Hub. Задайте подключение службы и выберите пространство имен, репозиторий, версию и псевдоним источника.
- Выберите триггер и переключите триггер непрерывного развертывания, чтобы включить. Каждый push Docker, выполняемый в выбранный репозиторий, создает релиз.
- Создайте новый этап и задание. Добавьте две задачи: вход в Docker и Bash.
- Задача Docker имеет действие
login
и выполняет вход на Docker Hub. - Задача Bash выполняется
docker pull <hub-user>/<repo-name>[:<tag>]
.
- Задача Docker имеет действие
Как проверить и диагностировать проблемы вебхука?
Создайте подключение к службе.
Укажите подключение к службе и задайте название веб-перехватчика в разделе
webhooks
.resources: webhooks: - webhook: MyWebhookTriggerAlias connection: MyServiceConnection
Запустите свой конвейер. Веб-перехватчик создается в Azure в качестве распределенной задачи для вашей организации.
Выполните 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 ...
, код может находиться в ветви, которая не ветвь по умолчанию. Чтобы устранить эту проблему, выполните следующие действия:
- Выберите "Изменить" на странице конвейера.
- В меню "Дополнительные действия" выберите "Триггеры".
- Выберите вкладку YAML и выберите " Получить источники".
- В разделе "Ветвь по умолчанию для ручных и запланированных сборок", обновите свою функциональную ветвь.
- Нажмите Сохранить и поместить в очередь.
- После успешного выполнения этого конвейера выполните вызов API, передавая допустимый JSON в теле запроса на
POST
. Теперь вы должны получить ответ на код состояния 200.