Определение ресурсов в 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 to pick the artifact, defaults to latest pipeline successful 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 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и branchtags свойствами.

Указанные свойства Версия артефакта
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, так и PreProductionSignedпосле завершения 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, , githubgithubenterpriseи 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> идентификатор, который вы предоставили для ресурса репозитория.

resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.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

Использование 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 и т. д.), и активировать свои конвейеры.

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

  1. Настройте веб-перехватчик во внешней службе. При создании веб-перехватчика необходимо указать следующие сведения:

    • URL-адрес запроса

      https://dev.azure.com/<ADO Organization>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview

    • Секрет — необязательно. Если необходимо защитить полезные данные JSON, укажите значение Secret .

  2. Создайте подключение службы "Входящий веб-перехватчик". Это новое подключение представляет собой недавно представленный тип подключения к службе, который позволяет определить следующую важную информацию:

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

    Подключение службы входящих веб-перехватчиков

  3. В конвейерах YAML представлен новый тип webhooks ресурса. Чтобы подписаться на событие веб-перехватчика, определите ресурс веб-перехватчика в конвейере и укажите его на подключение службы входящих веб-перехватчиков. Кроме того, можно определить дополнительные фильтры в ресурсе веб-перехватчика на основе полезных данных JSON, чтобы настроить триггеры для каждого конвейера. Потребляйте полезные данные в виде переменных в заданиях.

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

  1. В области "Создание запуска" выберите "Ресурсы". Вы увидите список ресурсов, потребляемых в этом конвейере.

  2. Выберите ресурс и выберите определенную версию из списка доступных версий. Средство выбора версий ресурсов поддерживается для конвейера, сборки, репозитория, контейнера и ресурсов пакета.

    Средство выбора версий конвейера

Для ресурсов конвейера можно просмотреть все доступные запуски во всех ветвях. Выполните поиск по номеру конвейера или ветви. И выберите выполнение, которое выполнено успешно, завершилось сбоем или выполняется. Эта гибкость гарантирует, что вы можете запустить конвейер 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, в представлении выполнения отображается вкладка "Связанные конвейеры". Здесь можно найти все запуски конвейера, которые используют конвейер и артефакты из него.

Сведения о конвейерах CD в конвейере CI

Проблемы с триггером ресурсов YAML поддерживают и трассировку

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

Выберите

Триггеры ресурсов могут не выполняться по следующим причинам.

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

  • Если условия триггера не соответствуют, триггер не будет выполняться. Предупреждение отображается, чтобы понять, почему условия не совпадают.

    Активация проблем с поддержкой

Следующие шаги

Добавление и использование групп переменных

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

Почему следует использовать конвейеры resources вместо ярлыка download ?

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

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

Почему следует использовать resources вместо задачи download Pipeline Artifacts?

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

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

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

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

  2. Создайте классический конвейер выпуска и добавьте артефакт Docker Hub. Задайте подключение к службе. Выберите пространство имен, репозиторий, версию и псевдоним источника.

    Добавьте артефакт Docker Hub.

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

  4. Создайте новый этап и задание. Добавьте две задачи, имя входа Docker и Bash:

  • Задача Docker содержит login действие и регистрирует вас в Docker Hub.

  • Выполняется docker pull <hub-user>/<repo-name>[:<tag>]задача Bash. Замените hub-user, repo-nameа также tag значениями.

    Добавьте задачи входа Docker и 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. Выберите меню Выберите меню дополнительных действий.
    4. Выберите триггеры>YAML>Get Sources.
    5. Перейдите в ветвь по умолчанию для ручной и запланированной сборки, чтобы обновить ветвь компонента.
    6. Нажмите Сохранить и поместить в очередь.
    7. После успешного выполнения этого конвейера выполните вызов API с допустимым POST JSON в тексте https://dev.azure.com/{organization}/_apis/public/distributedtask/webhooks/{webhook-name}?api-version={apiversion}. Теперь вы должны получить ответ на код состояния 200.