Определение ресурсов в YAML
Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019
Ресурсы в YAML представляют источники конвейеров, сборок, репозиториев, контейнеров, пакетов и веб-перехватчиков. Ресурсы также обеспечивают полную трассировку служб, используемых в конвейере, включая версию, артефакты, связанные фиксации и рабочие элементы. При определении ресурса его можно использовать в любом месте конвейера. И вы можете полностью автоматизировать рабочий процесс DevOps, подписавшись на активацию событий в ресурсах.
Дополнительные сведения см. в разделе "Сведения о ресурсах и определении схемы YAML".
Схема
resources:
pipelines: [ pipeline ]
builds: [ build ]
repositories: [ repository ]
containers: [ container ]
packages: [ package ]
webhooks: [ webhook ]
Переменные
Когда ресурс активирует конвейер, будут заданы следующие переменные:
resources.triggeringAlias
resources.triggeringCategory
Эти значения пусты, если ресурс не запускает выполнение конвейера. Переменная Build.Reason
должна быть ResourceTrigger
для получения этих значений.
pipelines
Определение ресурса
Если у вас есть конвейер, который создает артефакты, можно использовать артефакты, определив pipelines
ресурс. pipelines
— это выделенный ресурс только для Azure Pipelines. Вы также можете задать триггеры в ресурсе конвейера для рабочих процессов CD.
В определении pipeline
ресурса можно использовать уникальное значение, которое можно использовать для ссылки на ресурс конвейера позже. source
— это имя конвейера, создающего артефакт. Используйте метку, определенную для pipeline
ссылки на ресурс конвейера из других частей конвейера, например при использовании переменных ресурса конвейера или скачивании артефактов.
Альтернативный способ скачивания конвейеров см. в задачах в артефактах конвейера.
resources: # types: pipelines | builds | repositories | containers | packages
pipelines:
- pipeline: string # identifier for the resource used in pipeline resource variables
project: string # project for the source; optional for current project
source: string # name of the pipeline that produces an artifact. If it is in a different pipelines folder, it needs to be the full path, e.g. MyTeam/MyPipeline
version: string # the pipeline run number (Build.BuildNumber) to pick the artifact, defaults to latest pipeline successful run across all stages; Used only for manual or scheduled triggers
branch: string # branch to pick the artifact, optional; defaults to all branches; Used only for manual or scheduled triggers
tags: [ string ] # list of tags required on the pipeline to pickup default artifacts, optional; Used only for manual or scheduled triggers
trigger: # triggers aren't enabled by default unless you add trigger section to the resource
branches: # branch conditions to filter the events, optional; Defaults to all branches.
include: [ string ] # branches to consider for the trigger events, optional; Defaults to all branches.
exclude: [ string ] # branches to discard the trigger events, optional; Defaults to none.
tags: [ string ] # list of tags to evaluate for trigger event, optional
stages: [ string ] # list of stages to evaluate for trigger event, optional
Внимание
При определении триггера ресурса, если его ресурс конвейера находится из того же репозитория (например, само), что и текущий конвейер, активирует ту же ветвь и фиксацию, для которой вызывается событие. Но если ресурс конвейера находится из другого репозитория, текущий конвейер активируется в ветвь по умолчанию самостоятельного репозитория.
Оценка версии артефакта
Версия артефактов конвейера ресурсов зависит от того, как активируется конвейер.
Если конвейер выполняется, так как вы вручную активировали его или из-за запланированного выполнения, версия версии артефакта определяется значениями version
и branch
tags
свойствами.
Указанные свойства | Версия артефакта |
---|---|
version |
Артефакты сборки с указанным номером выполнения |
branch |
Артефакты из последней сборки, выполняемой в указанной ветви |
tags Список |
Артефакты из последней сборки с указанными тегами |
branch и tags список |
Артефакты из последней сборки, выполненной в указанной ветви , и все указанные теги |
нет | Артефакты из последней сборки во всех ветвях |
Давайте рассмотрим пример. Предположим, что конвейер содержит следующее определение ресурса.
resources:
pipelines:
- pipeline: MyCIAlias
project: Fabrikam
source: Farbrikam-CI
branch: main ### This branch input cannot have wild cards. It is used for evaluating default version when pipeline is triggered manually or scheduled.
tags: ### These tags are used for resolving default version when the pipeline is triggered manually or scheduled
- Production ### Tags are AND'ed
- PreProduction
При запуске конвейера вручную версия артефактов MyCIAlias
конвейера является одной из последних сборок, выполненных в main
ветви, и с Production
тегами и PrepProduction
тегами.
Когда конвейер активируется из-за завершения одного из конвейеров ресурсов, версия артефактов является одной из триггерных конвейеров. Значения version
свойств branch
и tags
свойств игнорируются.
Указанные триггеры | Результат |
---|---|
branches |
Новый запуск текущего конвейера активируется при успешном завершении выполнения конвейера ресурсов в include ветвях. |
tags |
Новый запуск текущего конвейера активируется всякий раз, когда конвейер ресурсов успешно завершает выполнение, помеченное всеми указанными тегами. |
stages |
При успешном выполнении указанного конвейера запускается новый запуск текущего конвейера ресурсов. stages |
branches , tags и stages |
Новый запуск текущего конвейера активируется всякий раз, когда конвейер ресурсов удовлетворяет всем условиям ветви, тегов и этапов. |
trigger: true |
Новый запуск текущего конвейера активируется при успешном завершении выполнения конвейера ресурсов. |
Ничего | При успешном завершении выполнения конвейера ресурсов не запускается новый запуск текущего конвейера. |
Давайте рассмотрим пример. Предположим, что конвейер содержит следующее определение ресурса.
resources:
pipelines:
- pipeline: SmartHotel
project: DevOpsProject
source: SmartHotel-CI
trigger:
branches:
include:
- releases/*
- main
exclude:
- topic/*
tags:
- Verified
- Signed
stages:
- Production
- PreProduction
Конвейер будет выполняться всякий раз, когда SmartHotel-CI
конвейер выполняется в одной из releases
ветвей или в main
ветви, помечается как с обоимиVerified
, так и PreProduction
Signed
после завершения Production
обоих этапов.
download
для конвейеров
Все артефакты из текущего конвейера и из всех pipeline
ресурсов автоматически скачиваются и становятся доступными в начале каждого deployment
задания. Это поведение можно переопределить. Дополнительные сведения см. в разделе "Артефакты конвейера". Обычные артефакты job не загружаются автоматически. Используйте download
явно при необходимости.
steps:
- download: [ current | pipeline resource identifier | none ] # disable automatic download if "none"
artifact: string ## artifact name, optional; downloads all the available artifacts if not specified
patterns: string # patterns representing files to include; optional
Артефакты из ресурса загружаются в pipeline
$(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier>
папку.
Переменные ресурса конвейера
В каждом запуске метаданные для ресурса конвейера доступны всем заданиям в виде предопределенных переменных. Это <Alias>
идентификатор, который вы предоставили для ресурса конвейера. Переменные ресурсов конвейера доступны только во время выполнения.
Дополнительные сведения о синтаксисе переменных см. в разделе "Определение переменных".
resources.pipeline.<Alias>.projectID
resources.pipeline.<Alias>.pipelineName
resources.pipeline.<Alias>.pipelineID
resources.pipeline.<Alias>.runName
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID
Дополнительные сведения см. в разделе Метаданные ресурса конвейера в виде предопределенных переменных.
builds
Определение ресурса
Если у вас есть внешняя система сборки CI, которая создает артефакты, можно использовать артефакты с ресурсом builds
. Ресурс builds
может быть любым внешними системами CI, такими как Jenkins, TeamCity, CircleCI и т. д.
resources: # types: pipelines | builds | repositories | containers | packages
builds:
- build: string # identifier for the build resource
type: string # the type of your build service like Jenkins, circleCI etc.
connection: string # service connection for your build service.
source: string # source definition of the build
version: string # the build number to pick the artifact, defaults to Latest successful build
trigger: boolean # Triggers aren't enabled by default and should be explicitly set
builds
— это расширяемая категория. Вы можете написать расширение для использования артефактов из службы сборок и ввести новый тип службы в составе builds
. Jenkins — это тип ресурса в builds
.
Внимание
Триггеры поддерживаются только для размещенных Jenkins, где Azure DevOps имеет вид с сервером Jenkins.
downloadBuild
задача для сборок
Артефакты из ресурса можно использовать в build
рамках заданий downloadBuild
с помощью задачи. В зависимости от типа определенного build
ресурса эта задача автоматически разрешает соответствующую задачу скачивания для службы во время выполнения.
Артефакты из ресурса загружаются в build
$(PIPELINE.WORKSPACE)/<build-identifier>/
папку.
Внимание
build
Артефакты ресурсов не загружаются автоматически в заданиях или заданиях deploy-jobs. Необходимо явно добавить downloadBuild
задачу для использования артефактов.
- downloadBuild: string # identifier for the resource from which to download artifacts
artifact: string # artifact to download; if left blank, downloads all artifacts associated with the resource provided
patterns: string | [ string ] # a minimatch path or list of [minimatch paths](tasks/file-matching-patterns.md) to download; if blank, the entire artifact is downloaded
repositories
Определение ресурса
Если в конвейере есть шаблоны в другом репозитории или вы хотите использовать многорепетный проверка с репозиторием, для которого требуется подключение к службе, необходимо сообщить системе об этом репозитории.
Ключевое слово repository
позволяет указать внешний репозиторий.
resources:
repositories:
- repository: string # Required as first property. Alias for the repository.
endpoint: string # ID of the service endpoint connecting to this repository.
trigger: none | trigger | [ string ] # CI trigger for this repository, no CI trigger if skipped (only works for Azure Repos).
name: string # repository name (format depends on 'type'; does not accept variables).
ref: string # ref name to checkout; defaults to 'refs/heads/main'. The branch checked out by default whenever the resource trigger fires.
type: string # Type of repository: git, github, githubenterprise, and bitbucket.
Тип
Конвейеры поддерживают следующие значения для типа репозитория: git
, , github
githubenterprise
и bitbucket
.
Тип git
относится к репозиториям Azure Repos Git.
Указанный тип | Результат | Пример |
---|---|---|
type: git |
Значение name ссылается на другой репозиторий в том же проекте. |
name: otherRepo Чтобы ссылаться на репозиторий в другом проекте в той же организации, префиксировать имя с именем этого проекта. Например, name: OtherProject/otherRepo . |
type: github |
Это name полное имя репозитория GitHub и включает пользователя или организацию. |
name: Microsoft/vscode |
type: githubenterprise |
name это полное имя репозитория GitHub Enterprise и включает пользователя или организацию. |
name: Microsoft/vscode |
type: bitbucket |
Это name полное имя репозитория Bitbucket Cloud и включает пользователя или организацию. |
name: MyBitbucket/vscode |
Репозитории GitHub Enterprise требуют подключения службы GitHub Enterprise для авторизации.
Bitbucket Cloud repos требует подключения к облачной службе Bitbucket для авторизации.
Переменные
В каждом запуске метаданные ресурса репозитория доступны всем заданиям в виде переменных среды выполнения. Это <Alias>
идентификатор, который вы предоставили для ресурса репозитория.
Переменные
В каждом запуске метаданные ресурса репозитория доступны всем заданиям в виде переменных среды выполнения. Это <Alias>
идентификатор, который вы предоставили для ресурса репозитория.
Использование checkout
репозитория
Используйте checkout
ключевое слово для использования репозиториев, определенных repository
как часть ресурса.
Схема
steps:
- checkout: string # Required as first property. Configures checkout for the specified repository.
clean: string # If true, run git clean -ffdx followed by git reset --hard HEAD before fetching.
fetchDepth: string # Depth of Git graph to fetch.
fetchTags: string # Set to 'true' to sync tags when fetching the repo, or 'false' to not sync tags. See remarks for the default behavior.
lfs: string # Set to 'true' to download Git-LFS files. Default is not to download them.
persistCredentials: string # Set to 'true' to leave the OAuth token in the Git config after the initial fetch. The default is not to leave it.
submodules: string # Set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules. Default is not to fetch submodules.
path: string # Where to put the repository. The default is $(Build.SourcesDirectory).
condition: string # Evaluate this condition expression to determine whether to run this task.
continueOnError: boolean # Continue running even on failure?
displayName: string # Human-readable name for the task.
target: string | target # Environment in which to run this task.
enabled: boolean # Run this task when the job runs?
env: # Variables to map into the process's environment.
string: string # Name/value pairs
name: string # ID of the step.
timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.
retryCountOnTaskFailure: string # Number of retries if the task fails.
Репозитории из repository
ресурса не синхронизируются автоматически в заданиях. Используйте checkout
для получения репозиториев в рамках заданий.
Дополнительные сведения см. в статье о нескольких репозиториях в конвейере.
containers
Определение ресурса
Если вам нужно использовать образ контейнера в рамках конвейера непрерывной интеграции и непрерывной доставки (CI/CD), его можно достичь с помощью containers
. Ресурс контейнера может быть общедоступным или частным реестром Docker или Реестр контейнеров Azure.
Если вам нужно использовать образы из реестра Docker в рамках конвейера, можно определить универсальный ресурс контейнера (не type
ключевое слово обязательно).
resources:
containers:
- container: string # identifier (A-Z, a-z, 0-9, and underscore)
image: string # container image name
options: string # arguments to pass to container at startup
endpoint: string # reference to a service connection for the private registry
env: { string: string } # list of environment variables to add
ports: [ string ] # ports to expose on the container
volumes: [ string ] # volumes to mount on the container
mapDockerSocket: bool # whether to map in the Docker daemon socket; defaults to true
mountReadOnly: # volumes to mount read-only - all default to false
externals: boolean # components required to talk to the agent
tasks: boolean # tasks required by the job
tools: boolean # installable tools like Python and Ruby
work: boolean # the work directory
Универсальный ресурс контейнера можно использовать в качестве образа, используемого в рамках задания, или его также можно использовать для заданий контейнеров. Если конвейеру требуется поддержка одной или нескольких служб, необходимо создать и подключиться к контейнерам служб. Тома можно использовать для совместного использования данных между службами.
Для использования образов ACR можно использовать тип ресурса контейнера первого класса для Реестр контейнеров Azure (ACR). Этот тип ресурсов можно использовать как часть заданий, а также для включения автоматических триггеров конвейера. Для ACR необходимо иметь разрешения участника или владельца , чтобы использовать автоматические триггеры конвейера. Дополнительные сведения см. в разделе Реестр контейнеров Azure ролях и разрешениях.
resources: # types: pipelines | repositories | containers | builds | packages
containers:
- container: string # identifier for the container resource
type: string # type of the registry like ACR, GCR etc.
azureSubscription: string # Azure subscription (ARM service connection) for container registry;
resourceGroup: string # resource group for your ACR
registry: string # registry for container images
repository: string # name of the container image repository in ACR
trigger: # Triggers aren't enabled by default and need to be set explicitly
enabled: boolean # set to 'true' to trigger on all image tags if 'tags' is unset.
tags:
include: [ string ] # image tags to consider the trigger events, optional; defaults to any new tag
exclude: [ string ] # image tags on discard the trigger events, optional; defaults to none
Примечание.
Синтаксис, используемый для включения триггеров контейнера для всех тегов изображений (enabled: 'true'
) отличается от синтаксиса, используемого для других триггеров ресурсов. Обратите особое внимание на использование правильного синтаксиса для определенного ресурса.
Примечание.
Подключения службы, использующие федерацию удостоверений рабочей нагрузки, не поддерживаются azureSubscription
.
Переменные ресурсов контейнера
После определения контейнера как ресурса метаданные образа контейнера передаются в конвейер в виде переменных. Сведения об образе, реестре и подключении доступны во всех заданиях, которые будут использоваться в задачах развертывания контейнера.
Переменные ресурсов контейнера работают с Docker и Реестр контейнеров Azure. Нельзя использовать переменные ресурсов контейнера для контейнеров локальных образов.
resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location
Переменная расположения применима только к ACR
типу ресурсов контейнера.
packages
Определение ресурса
Пакеты NuGet и npm GitHub можно использовать в качестве ресурса в конвейерах YAML.
При указании package
ресурсов задайте пакет как NuGet или npm. Вы также можете включить автоматические триггеры конвейера при выпуске новой версии пакета.
Чтобы использовать пакеты GitHub, используйте проверку подлинности на основе ЛИЧНЫХ маркеров доступа (PAT) и создайте подключение службы GitHub, использующее PATS.
По умолчанию пакеты не загружаются автоматически в задания. Чтобы скачать, используйте getPackage
.
resources:
packages:
- package: myPackageAlias # alias for the package resource
type: Npm # type of the package NuGet/npm
connection: GitHubConnectionName # GitHub service connection with the PAT type
name: nugetTest/nodeapp # <Repository>/<Name of the package>
version: 1.0.1 # Version of the package to consume; Optional; Defaults to latest
trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers
webhooks
Определение ресурса
Примечание.
Веб-перехватчики были выпущены в Azure DevOps Server 2020.1.
С другими ресурсами (такими как конвейеры, контейнеры, сборки и пакеты) вы можете использовать артефакты и задействовать автоматические триггеры. Однако вы не можете автоматизировать процесс развертывания на основе других внешних событий или служб. Ресурс webhooks
позволяет интегрировать конвейер с любой внешней службой и автоматизировать рабочий процесс. Вы можете подписаться на любые внешние события, используя их веб-перехватчики (GitHub, GitHub Enterprise, Nexus, Artifactory и т. д.), и активировать свои конвейеры.
Выполните следующие действия, чтобы настроить триггеры веб-перехватчика.
Настройте веб-перехватчик во внешней службе. При создании веб-перехватчика необходимо указать следующие сведения:
URL-адрес запроса
https://dev.azure.com/<ADO Organization>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview
Секрет — необязательно. Если необходимо защитить полезные данные JSON, укажите значение Secret .
Создайте подключение службы "Входящий веб-перехватчик". Это новое подключение представляет собой недавно представленный тип подключения к службе, который позволяет определить следующую важную информацию:
- Имя веб-перехватчика: имя веб-перехватчика должно соответствовать веб-перехватчику, созданному во внешней службе.
- Заголовок HTTP — имя заголовка HTTP в запросе, содержащего хэш-значение HMAC-SHA1 полезных данных для проверки запроса. Например, для GitHub заголовок запроса — X-Hub-Signature.
- Секрет — секрет используется для проверки хэша HMAC-SHA1 полезных данных, используемого для проверки входящего запроса (необязательно). Если вы использовали секрет при создании своего веб-перехватчика, обязательно укажите такой же секретный ключ.
В конвейерах YAML представлен новый тип
webhooks
ресурса. Чтобы подписаться на событие веб-перехватчика, определите ресурс веб-перехватчика в конвейере и укажите его на подключение службы входящих веб-перехватчиков. Кроме того, можно определить дополнительные фильтры в ресурсе веб-перехватчика на основе полезных данных JSON, чтобы настроить триггеры для каждого конвейера. Потребляйте полезные данные в виде переменных в заданиях.Всякий раз, когда подключение к службе входящего веб-перехватчика получает событие веб-перехватчика, новое выполнение активируется для всех конвейеров, подписанных событием веб-перехватчика. Полезные данные JSON можно использовать в заданиях с помощью формата
${{ parameters.<WebhookAlias>.<JSONPath>}}
resources:
webhooks:
- webhook: MyWebhookTriggerAlias ### Webhook alias
connection: IncomingWebhookConnection ### Incoming webhook service connection
filters: ### List of JSON parameters to filter; Parameters are AND'ed
- path: JSONParameterPath ### JSON path in the payload
value: JSONParameterExpectedValue ### Expected value in the path provided
Веб-перехватчики автоматизируют рабочий процесс на основе любого внешнего события веб-перехватчика, которое не поддерживается ресурсами первого класса, такими как конвейеры, сборки, контейнеры и пакеты. Кроме того, для локальных служб, где Azure DevOps не имеет видимости процесса, вы можете настроить веб-перехватчики в службе и автоматически активировать конвейеры.
Средство выбора версий вручную для ресурсов в диалоговом окне создания запуска
При запуске конвейера CD YAML вручную мы автоматически вычисляем версию по умолчанию для ресурсов, определенных в конвейере, на основе предоставленных входных данных. Однако при создании запуска можно выбрать другую версию из средства выбора версий ресурсов.
В области "Создание запуска" выберите "Ресурсы". Вы увидите список ресурсов, потребляемых в этом конвейере.
Выберите ресурс и выберите определенную версию из списка доступных версий. Средство выбора версий ресурсов поддерживается для конвейера, сборки, репозитория, контейнера и ресурсов пакета.
Для ресурсов конвейера можно просмотреть все доступные запуски во всех ветвях. Выполните поиск по номеру конвейера или ветви. И выберите выполнение, которое выполнено успешно, завершилось сбоем или выполняется. Эта гибкость гарантирует, что вы можете запустить конвейер CD, если вы уверены, что он создал все необходимые артефакты. Не нужно ждать завершения или повторного запуска CI из-за несвязанного сбоя этапа в выполнении CI. Однако при оценке версии по умолчанию для запланированных триггеров мы рассматриваем только успешно завершенные операции CI или если вы не используете средство выбора версий вручную.
Для ресурсов, в которых вы не можете получить доступные версии, например пакеты GitHub, мы отображаем текстовое поле как часть средства выбора версий, чтобы предоставить версию для выбора запуска.
Авторизация конвейера YAML
Чтобы их можно было использовать, ресурсы должны быть авторизованы. Владелец ресурса управляет пользователями и конвейерами, которые могут получить доступ к такому ресурсу. Конвейер должен быть авторизован для использования ресурса. См. следующие способы авторизации конвейера 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. Настройка требуемого утверждения шаблона повышает безопасность. Убедитесь, что ресурс используется только в определенных условиях с шаблоном. Узнайте больше о том, как повысить безопасность конвейера с помощью шаблонов и ресурсов.
Возможность трассировки
Мы предоставляем полную трассировку для любого ресурса, используемого на уровне задания конвейера или развертывания.
Трассировка конвейера
Для каждого запуска конвейера отображаются следующие сведения.
Ресурс, активировав конвейер, если он активируется ресурсом.
Версия ресурса и используемых артефактов.
Фиксации, связанные с каждым ресурсом.
Рабочие элементы, связанные с каждым ресурсом.
Возможность трассировки среды
При каждом развертывании конвейера в среде можно просмотреть список используемых ресурсов. В следующем представлении содержатся ресурсы, используемые в рамках заданий развертывания, а также связанные с ними фиксации и рабочие элементы.
Отображение сведений о связанных конвейерах CD в конвейерах CI
Чтобы обеспечить сквозную трассировку, можно отслеживать, какие конвейеры CD используют конвейер CI. Список конвейеров CD YAML отображается, где выполняется конвейер CI, используемый pipeline
через ресурс. Если другие конвейеры используют конвейер CI, в представлении выполнения отображается вкладка "Связанные конвейеры". Здесь можно найти все запуски конвейера, которые используют конвейер и артефакты из него.
Проблемы с триггером ресурсов YAML поддерживают и трассировку
Это может быть запутано, когда триггеры конвейера не выполняются. Мы добавили новый пункт меню на странице определения конвейера с именем "Проблемы триггера", где можно узнать, почему триггеры не выполняются. Чтобы получить доступ к этой странице, откройте журнал конвейера. Проблемы триггера доступны только для ресурсов, отличных от репозитория.
Триггеры ресурсов могут не выполняться по следующим причинам.
Если источник предоставленного подключения службы недопустим или если в триггере есть ошибки синтаксиса, триггер не настроен, в результате чего возникает ошибка.
Если условия триггера не соответствуют, триггер не будет выполняться. Предупреждение отображается, чтобы понять, почему условия не совпадают.
Следующие шаги
Вопросы и ответы
Почему следует использовать конвейеры resources
вместо ярлыка download
?
pipelines
Использование ресурса — это способ использования артефактов из конвейера CI, а также настройки автоматических триггеров. Ресурс обеспечивает полную видимость процесса путем отображения используемой версии, артефактов, фиксаций и рабочих элементов. При определении ресурса конвейера связанные артефакты автоматически загружаются в заданиях развертывания.
Вы можете скачать артефакты в заданиях сборки или переопределить поведение загрузки в заданиях развертывания.download
Дополнительные сведения см. в разделе steps.download.
Почему следует использовать resources
вместо задачи download Pipeline Artifacts?
При использовании задачи "Скачать артефакты конвейера" напрямую отсутствует возможность трассировки и триггеры. Иногда имеет смысл использовать задачу "Скачать артефакты конвейера" напрямую. Например, у вас может быть задача скрипта, хранящуюся в другом шаблоне, и задача скрипта требует загрузки артефактов из сборки. Кроме того, возможно, вы не знаете, хочет ли пользователь, использующий шаблон, добавить ресурс конвейера. Чтобы избежать зависимостей, можно использовать задачу download Pipeline Artifacts для передачи всех сведений о сборке в задачу.
Как активировать запуск конвейера при обновлении образа Docker Hub?
Вам потребуется настроить классический конвейер выпуска, так как триггер ресурса контейнеров недоступен для конвейеров Docker Hub для YAML.
Создайте подключение службы Docker Hub.
Создайте классический конвейер выпуска и добавьте артефакт Docker Hub. Задайте подключение к службе. Выберите пространство имен, репозиторий, версию и псевдоним источника.
Выберите триггер и переключите триггер непрерывного развертывания, чтобы включить. Вы создадите выпуск каждый раз при отправке Docker в выбранный репозиторий.
Создайте новый этап и задание. Добавьте две задачи, имя входа Docker и Bash:
Задача Docker содержит
login
действие и регистрирует вас в Docker Hub.Выполняется
docker pull <hub-user>/<repo-name>[:<tag>]
задача Bash. Заменитеhub-user
,repo-name
а такжеtag
значениями.
Как проверить и устранить неполадки веб-перехватчиков?
Создайте подключение к службе.
Обратитесь к подключению к службе и назовите веб-перехватчик в
webhooks
разделе.resources: webhooks: - webhook: MyWebhookTriggerAlias connection: MyServiceConnection
Запустите свой конвейер. При запуске конвейера веб-перехватчик будет создан в Azure в качестве распределенной задачи для вашей организации.
Выполните вызов API с допустимым
POST
JSON в текстеhttps://dev.azure.com/{organization}/_apis/public/distributedtask/webhooks/{webhook-name}?api-version={apiversion}
. Если вы получите ответ на код состояния 200, веб-перехватчик готов к использованию конвейером. Если вы получаете ответ на код состояния 500 с ошибкойCannot find webhook for the given webHookId ...
, код может находиться в ветви, которая не является вашей ветвь по умолчанию.- Откройте конвейер.
- Выберите Изменить.
- Выберите меню дополнительных действий.
- Выберите триггеры>YAML>Get Sources.
- Перейдите в ветвь по умолчанию для ручной и запланированной сборки, чтобы обновить ветвь компонента.
- Нажмите Сохранить и поместить в очередь.
- После успешного выполнения этого конвейера выполните вызов API с допустимым
POST
JSON в текстеhttps://dev.azure.com/{organization}/_apis/public/distributedtask/webhooks/{webhook-name}?api-version={apiversion}
. Теперь вы должны получить ответ на код состояния 200.
Связанные статьи
Обратная связь
https://aka.ms/ContentUserFeedback.
Ожидается в ближайшее время: в течение 2024 года мы постепенно откажемся от GitHub Issues как механизма обратной связи для контента и заменим его новой системой обратной связи. Дополнительные сведения см. в разделеОтправить и просмотреть отзыв по