Бөлісу құралы:

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

  • Мақала

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

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

Версия артефакта конвейера ресурсов зависит от того, как триггеры конвейера.

Ручной или запланированный триггер

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

Указанные свойства Версия артефакта
version Артефакты сборки с указанным номером выполнения
branch Артефакты из последней сборки, выполненной в указанной ветви
tags список Артефакты из последней сборки с указанными тегами
branch и tags список Артефакты из последней сборки, выполненной в указанной ветви, которая содержит все указанные теги.
нет Артефакты из последней сборки во всех ветвях

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

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

  • Выполняется в одной из 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> folder. Дополнительные сведения см. в статье "Публикация и скачивание артефактов конвейера".

Необязательное 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.

В следующем примере 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, , githubgithubenterpriseи 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.container.container.

Примечание.

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

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

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

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

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

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

Примечание.

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

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

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

Переменные ресурсов контейнера работают с Docker и Реестр контейнеров Azure. Нельзя использовать переменные ресурсов контейнера для контейнеров локальных образов. Переменная 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 contosoпакета npm GitHub. Дополнительные сведения см. в статье о пакетах 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 и артефакты из него.

Снимок экрана: сведения о конвейерах CD в конвейере 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.
    • Выполняется docker pull <hub-user>/<repo-name>[:<tag>]задача Bash.

Как проверить и устранить неполадки веб-перехватчика?

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

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

    resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias
      connection: MyServiceConnection

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

  4. Выполните вызов 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 ..., код может находиться в ветви, которая не ветвь по умолчанию. Чтобы устранить эту проблему, выполните следующие действия:

  1. Выберите "Изменить" на странице конвейера.
  2. В меню "Дополнительные действия" выберите "Триггеры".
  3. Выберите вкладку YAML и выберите " Получить источники".
  4. В разделе "Ветвь по умолчанию" для ручных и запланированных сборок обновите ветвь компонента.
  5. Нажмите Сохранить и поместить в очередь.
  6. После успешного выполнения этого конвейера выполните вызов API с допустимым POST JSON в тексте https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>. Теперь вы должны получить ответ на код состояния 200.

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