Definir recursos no YAML

  • Artigo

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Os recursos em YAML representam fontes de pipelines, builds, repositórios, contêineres, pacotes e webhooks. Os recursos também fornecem a rastreabilidade total dos serviços usados no pipeline, incluindo a versão, os artefatos, os commits associados e os itens de trabalho. Quando você define um recurso, ele pode ser consumido em qualquer lugar no seu pipeline. Além disso, você pode automatizar totalmente o seu fluxo de trabalho de DevOps fazendo uma assinatura para disparar eventos nos seus recursos.

Para obter mais informações, confira Sobre recursos e a definição do esquema YAML de recursos.

Esquema

resources:
  pipelines: [ pipeline ]  
  builds: [ build ]
  repositories: [ repository ]
  containers: [ container ]
  packages: [ package ]
  webhooks: [ webhook ]

Variáveis

Quando um recurso dispara um pipeline, as seguintes variáveis são definidas:

resources.triggeringAlias
resources.triggeringCategory

Esses valores estarão vazios se um recurso não disparar uma execução de pipeline. A variável Build.Reason deve ser ResourceTrigger para que esses valores sejam definidos.

Definir um recurso pipelines

Se você tiver um pipeline que produz artefatos, poderá consumir os artefatos definindo um recurso pipelines. pipelines é um recurso dedicado somente para Azure Pipelines. Você também pode definir gatilhos em um recurso do pipeline para seus fluxos de trabalho de CD.

Na sua definição de recurso, pipeline é um valor exclusivo que você pode usar para referenciar o recurso do pipeline posteriormente. source é o nome do pipeline que produz um artefato. Use o rótulo definido por pipeline para referenciar o recurso do pipeline de outras partes do pipeline, como ao usar variáveis de recurso do pipeline ou baixar artefatos.

Para obter uma maneira alternativa de baixar pipelines, confira as tarefas em Artefatos de 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

Importante

Quando você define um gatilho de recurso, se seu recurso do pipeline for do mesmo repositório (digamos o self) que o pipeline atual, o disparo seguirá o mesmo branch e confirmará em que o evento é gerado. Mas, se o recurso do pipeline for de um repositório diferente, o pipeline atual será disparado no branch padrão do repositório self.

Avaliação da versão do artefato

A versão dos artefatos do pipeline de recursos depende de como o pipeline é disparado.

Se o seu pipeline for executado porque você o disparou manualmente ou devido a uma execução agendada, a versão do artefato será definida pelos valores das propriedades version, branch e tags.

Propriedades especificadas Versão do artefato
version Os artefatos do build com o número de execução especificado
branch Os artefatos do build mais recente executado no branch especificado
Lista tags Os artefatos do build mais recente que tem todas as marcas especificadas
Lista branch e tags Os artefatos do build mais recente executado no branch especificado e que tem todas as marcas especificadas
Nenhum Os artefatos do build mais recente em todos os branches

Vamos examinar um exemplo. Digamos que o pipeline contém a definição de recurso a seguir.

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

Quando você dispara manualmente o pipeline para execução, a versão dos artefatos do pipeline MyCIAlias é a do build mais recente feito no branch main e que tem as marcas Production e PrepProduction.

Quando o pipeline é disparado porque um dos pipelines de recurso foi concluído, a versão dos artefatos é a do pipeline de gatilho. Os valores das propriedades version, branch e tags são ignorados.

Gatilhos especificados Resultado
branches Uma nova execução do pipeline atual é disparada sempre que o pipeline de recurso conclui com êxito uma execução nos branches include
tags Uma nova execução do pipeline atual é disparada sempre que o pipeline de recurso conclui com êxito uma execução marcada com todas as marcas especificadas
stages Uma nova execução do pipeline atual é disparada sempre que o pipeline de recurso executa com êxito o stages especificado
branches, tags, e stages Uma nova execução do pipeline atual é disparada sempre que a execução do pipeline de recursos atende a todas as condições de branch, marcas e fases
trigger: true Uma nova execução do pipeline atual é disparada sempre que o pipeline de recurso conclui com êxito uma execução
Nada Nenhuma nova execução do pipeline atual é disparada quando o pipeline de recurso conclui com êxito uma execução

Vamos examinar um exemplo. Digamos que o pipeline contém a definição de recurso a seguir.

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

Seu pipeline será executado sempre que o pipeline SmartHotel-CI for executado em uma das branches releases ou na branch main, estiver marcado com Verified e Signed, e tiver concluído as fases Production e PreProduction.

download para pipelines

Todos os artefatos do pipeline atual e de todos os recursos pipeline são baixados e disponibilizados automaticamente no início de cada trabalho deployment. Você pode substituir esse comportamento. Para obter mais informações, confira Artefatos de Pipeline. Os artefatos de 'trabalho' regulares não são baixados automaticamente. Use download explicitamente quando necessário.

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

Os artefatos do recurso pipeline são baixados na pasta $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier>.

Variáveis de recurso do pipeline

Em cada execução, os metadados de um recurso do pipeline estão disponíveis para todos os trabalhos na forma de variáveis predefinidas. O <Alias> é o identificador que você forneceu para o recurso do pipeline. As variáveis de recursos do pipeline só estão disponíveis em runtime.

Para saber mais sobre sintaxe de variáveis, consulte Definir variáveis.

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

Para obter mais informações, confira Metadados de recursos do pipeline como variáveis predefinidas.

Definir um recurso builds

Se você tiver um sistema de build de CI externo que produz artefatos, poderá consumir artefatos com um recurso builds. Um recurso builds pode ser qualquer sistema de CI externo, como Jenkins, TeamCity, CircleCI e assim por diante.

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 é uma categoria extensível. Você pode gravar uma extensão para consumir artefatos do serviço de builds e introduzir um novo tipo de serviço como parte do builds. Jenkins é um tipo de recurso no builds.

Importante

Só há suporte para gatilhos para Jenkins hospedado em que o Azure DevOps tem uma linha de visão com o servidor Jenkins.

Tarefa downloadBuild para builds

Você pode consumir artefatos do recurso build como parte dos seus trabalhos usando a tarefa downloadBuild. Com base no tipo de recurso build definido, essa tarefa é resolvida automaticamente para a tarefa de download correspondente do serviço durante o tempo de execução.

Os artefatos do recurso build são baixados na pasta $(PIPELINE.WORKSPACE)/<build-identifier>/.

Importante

Os artefatos do recurso build não são baixados automaticamente nos seus trabalhos/deploy-jobs. Você precisa adicionar explicitamente a tarefa downloadBuild para consumir os artefatos.

- 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

Definir um recurso repositories

Se o pipeline tiver modelos em outro repositório ou se você quiser usar o check-out de vários repositórios com um repositório que exija uma conexão de serviço, informe o sistema sobre esse repositório. A palavra-chave repository permite especificar um repositório externo.

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.

Type

Os pipelines dão suporte aos seguintes valores para o tipo de repositório: git, github, githubenterprise e bitbucket. O tipo git refere-se aos repositórios Git do Azure Repos.

Tipo especificado Resultado Exemplo
type: git O valor name refere-se a outro repositório no mesmo projeto. name: otherRepo Para referir-se a um repositório em outro projeto na mesma organização, use o nome desse projeto como prefixo. Um exemplo é name: OtherProject/otherRepo.
type: github O valor name é o nome completo do repositório GitHub e inclui o usuário ou a organização. name: Microsoft/vscode
type: githubenterprise O valor name é o nome completo do repositório GitHub Enterprise e inclui o usuário ou a organização. name: Microsoft/vscode
type: bitbucket O valor name é o nome completo do repositório Bitbucket Cloud e inclui o usuário ou a organização. name: MyBitbucket/vscode

Os repositórios GitHub Enterprise exigem uma conexão de serviço do GitHub Enterprise para autorização.

Os repositórios Bitbucket Cloud exigem uma conexão de serviço do Bitbucket Cloud para autorização.

Variáveis

Em cada execução, os metadados de um recurso de repositório estão disponíveis para todos os trabalhos na forma de variáveis de tempo de execução. O <Alias> é o identificador que você forneceu para o recurso do repositório.

resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.url

Variáveis

Em cada execução, os metadados de um recurso de repositório estão disponíveis para todos os trabalhos na forma de variáveis de tempo de execução. O <Alias> é o identificador que você forneceu para o recurso do repositório.

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

Usar checkout para consumir repositório

Use a palavra-chave checkout para consumir seus repositórios definidos como parte do recurso repository.

Esquema

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.

Os repositórios do recurso repository não são sincronizados automaticamente nos seus trabalhos. Use checkout para buscar seus repositórios como parte dos seus trabalhos.

Para obter informações, confira Fazer check-out de vários repositórios no pipeline.

Definir um recurso containers

Se você precisar consumir uma imagem de contêiner como parte do pipeline de CI/CD (integração contínua/entrega contínua), poderá obtê-la usando containers. Um recurso de contêiner pode ser um Registro do Docker público ou privado ou Registro de Contêiner do Azure.

Se você precisar consumir imagens do Registro do Docker como parte do pipeline, poderá definir um recurso de contêiner genérico (não requer a palavra-chave 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

Você pode usar um recurso de contêiner genérico como uma imagem consumida como parte do trabalho ou ele também pode ser usado para trabalhos de contêiner. Se o pipeline exigir o suporte de um ou mais serviços, você desejará criar e se conectar a contêineres de serviço. É possível usar volumes para compartilhar dados entre serviços.

Você pode usar um tipo de recurso de contêiner de primeira classe para ACR (Registro de Contêiner do Azure) para consumir suas imagens do ACR. Esse tipo de recursos pode ser usado como parte dos seus trabalhos e também para habilitar gatilhos de pipeline automáticos. Você precisa ter permissões de Colaborador ou Proprietário para que o ACR use gatilhos de pipeline automáticos. Para obter mais informações, confira Funções e permissões do Registro de Contêiner do 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

Observação

A sintaxe usada para habilitar gatilhos de contêiner para todas as marcas de imagem (enabled: 'true') é diferente da sintaxe usada para outros gatilhos de recurso. Preste muita atenção para usar a sintaxe correta de um recurso específico.

Observação

As conexões de serviço que usam a federação de identidade de carga de trabalho não são compatíveis com azureSubscription.

Variáveis de recurso de contêiner

Depois de definir um contêiner como um recurso, os metadados de imagem de contêiner são passados para o pipeline na forma de variáveis. Informações como imagem, registro e detalhes de conexão podem ser acessadas em todos os trabalhos a serem usados nas suas tarefas de implantação de contêiner.

As variáveis de recurso de contêiner funcionam com o Docker e o Registro de Contêiner do Azure. Não é possível usar variáveis de recurso de contêiner para contêineres de imagem local.

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

A variável de localização só é aplicável para o tipo ACR dos recursos de contêiner.

Definir um recurso packages

Você pode consumir pacotes NuGet e npm GitHub como um recurso em pipelines YAML.

Ao especificar recursos package, defina o pacote como NuGet ou npm. Você também poderá habilitar gatilhos de pipeline automatizados quando uma nova versão do pacote for lançada.

Para usar pacotes GitHub, use a autenticação baseada em PAT (token de acesso pessoal) e crie uma conexão de serviço do GitHub que usa PATs.

Por padrão, os pacotes não são baixados automaticamente nos trabalhos. Para baixar, use 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

Definir um recurso webhooks

Observação

Os webhooks foram lançados no Azure DevOps Server 2020.1.

Com outros recursos (como pipelines, contêineres, build e pacotes), você pode consumir artefatos e habilitar gatilhos automatizados. No entanto, você não pode automatizar seu processo de implantação com base em outros eventos ou serviços externos. O recurso webhooks permite que você integre seu pipeline a qualquer serviço externo e automatize o fluxo de trabalho. Você pode assinar quaisquer eventos externos usando os webhooks (GitHub, GitHub Enterprise, Nexus, Artifactory e assim por diante) e disparar seus pipelines.

Execute as etapas a seguir para configurar os gatilhos de webhook.

  1. Configure um webhook no seu serviço externo. Ao criar o webhook, você precisa fornecer as seguintes informações:

    • URL de Solicitação

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

    • Segredo – Opcional. Se você precisar proteger sua carga JSON, forneça o valor de Segredo.

  2. Crie uma nova conexão de serviço do "Webhook de Entrada". Essa conexão é um tipo de conexão de serviço recém-introduzido que permite definir as seguintes informações importantes:

    • Nome do webhook: o nome do webhook deve corresponder ao webhook criado no seu serviço externo.
    • Cabeçalho HTTP – O nome do cabeçalho HTTP na solicitação que contém o valor de hash HMAC-SHA1 da carga para verificação de solicitação. Por exemplo, para GitHub, o cabeçalho da solicitação é "X-Hub-Signature".
    • Segredo – O segredo é usado para verificar o hash HMAC-SHA1 da carga usado para verificação da solicitação de entrada (opcional). Se você usou um segredo ao criar o webhook, deverá fornecer a mesma chave de segredo.

    Conexão de Serviço do Webhook de Entrada

  3. Um novo tipo de recurso chamado webhooks foi introduzido em pipelines YAML. Para assinar um evento de webhook, defina um recurso de webhook no seu pipeline e aponte-o para a conexão de serviço do Webhook de Entrada. Você também pode definir mais filtros no recurso de webhook, com base nos dados de conteúdo JSON, para personalizar os gatilhos de cada pipeline. Consuma os dados de carga na forma de variáveis nos seus trabalhos.

  4. Sempre que a conexão de serviço do Webhook de Entrada recebe um evento de webhook, uma nova execução é disparada para todos os pipelines inscritos no evento webhook. Você pode consumir os dados de conteúdo JSON nos seus trabalhos usando o formato ${{ 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

Os webhooks automatizam o fluxo de trabalho com base em qualquer evento externo de webhook que não seja compatível com recursos de primeira classe, como pipelines, compilações, contêineres e pacotes. Além disso, para serviços locais em que o Azure DevOps não tem visibilidade do processo, você pode configurar webhooks no serviço e disparar seus pipelines automaticamente.

Seletor de versão manual para recursos na caixa de diálogo Criar execução

Quando você dispara manualmente um pipeline de CD YAML, avaliamos automaticamente a versão padrão para os recursos definidos no pipeline com base nas entradas fornecidas. No entanto, você pode escolher uma versão diferente do seletor de versão do recurso ao criar uma execução.

  1. No painel Criar execução, selecione Recursos. Você verá uma lista de recursos consumidos neste pipeline.

  2. Selecione um recurso e escolha uma versão específica na lista de versões disponíveis. O seletor de versão do recurso tem suporte para recursos de pipeline, build, repositório, contêiner e pacote.

    Seletor de versão do Pipeline

Para recursos do pipeline, você pode ver todas as execuções disponíveis em todos os branches. Pesquise-os com base no número ou branch do pipeline. E escolha uma execução bem-sucedida, com falha ou em andamento. Essa flexibilidade garante que você possa executar seu pipeline de CD, se tiver certeza de que ele produziu todos os artefatos necessários. Você não precisa esperar que a execução de CI seja concluída ou executada novamente devido a uma falha de fase não relacionada na execução de CI. No entanto, consideramos apenas as execuções de CI concluídas com êxito, quando avaliamos a versão padrão para gatilhos agendados ou se você não usa o seletor de versão manual.

Para recursos em que você não pode buscar as versões disponíveis, como pacotes do GitHub, mostramos uma caixa de texto como parte do seletor de versão para que você possa fornecer a versão para a execução escolher.

Autorizar um pipeline YAML

Os recursos devem ser autorizados para que possam ser usados. Um proprietário de recurso controla os usuários e pipelines que podem acessar esse recurso. O pipeline deve estar autorizado a usar o recurso. Veja as seguintes maneiras de autorizar um pipeline YAML.

  • Acesse a experiência de administração do recurso. Por exemplo, os grupos de variáveis e arquivos seguros são gerenciados na página Biblioteca em Pipelines. Os pools de agentes e as conexões de serviço são gerenciados nas configurações do Project. Aqui você pode autorizar todos os pipelines a acessar esse recurso. Essa autorização será conveniente se você não tiver a necessidade de restringir o acesso a um recurso, por exemplo, recursos de teste.

  • Quando você cria um pipeline pela primeira vez, todos os recursos referenciados no arquivo YAML são automaticamente autorizados para serem usados pelo pipeline, se você for membro da função Usuário para esse recurso. Portanto, os recursos referenciados no arquivo YAML quando você cria um pipeline são autorizados automaticamente.

  • Quando você faz alterações no arquivo YAML e adiciona recursos, o build falha com um erro semelhante ao seguinte: Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use.

    Nesse caso, você verá uma opção para autorizar os recursos no build com falha. Se você for membro da função Usuário do recurso, poderá selecionar essa opção. Depois que os recursos forem autorizados, você poderá iniciar um novo build.

  • Verifique se as funções de segurança do pool de agentes do projeto estão corretas.

Definir verificações de aprovação para recursos

Você pode controlar manualmente quando um recurso é executado com verificações de aprovação e modelos. Com a verificação de aprovação de modelo necessária, você pode exigir qualquer pipeline usando um recurso ou ambiente que também se estenda a partir de um modelo YAML específico. Definir uma aprovação de modelo necessária aprimora a segurança. Verifique se o recurso só é usado em condições específicas com um modelo. Saiba mais sobre como aprimorar a segurança do pipeline com modelos e recursos.

Rastreabilidade

Fornecemos rastreabilidade total para qualquer recurso consumido em um nível de trabalho de pipeline ou implantação.

Rastreabilidade de pipeline

Para cada execução de pipeline, mostramos as informações a seguir.

  • O recurso que disparou o pipeline, se ele for disparado por um recurso.

    Gatilho de recurso em um pipeline

  • Versão do recurso e os artefatos consumidos.

    Artefatos consumidos na execução de pipeline

  • Confirmações associadas a cada recurso.

    Confirmações na execução de pipeline

  • Itens de trabalho associados a cada recurso.

Rastreabilidade de ambiente

Sempre que um pipeline é implantado em um ambiente, você pode ver uma lista de recursos consumidos. A exibição a seguir inclui os recursos consumidos como parte dos trabalhos de implantação e as confirmações e itens de trabalho associados.

Confirmações no ambiente

Mostrar informações de pipelines de CD associados em pipelines de CI

Para fornecer rastreabilidade de ponta a ponta, você pode acompanhar quais pipelines de CD estão consumindo um pipeline de CI fornecido. Você pode ver a lista de execuções de pipelines YAML de CD em que uma execução de pipeline de CI é consumida pelo recurso pipeline. Se outros pipelines consumirem seu pipeline de CI, você verá uma guia "Pipelines associados" na exibição de execução. Aqui você pode encontrar todas as execuções de pipeline que consomem seu pipeline e os artefatos dele.

Informações de pipelines de CD em pipelines de CI

Suporte e rastreabilidade de problemas de gatilho de recurso YAML

Pode ser confuso quando os gatilhos de pipeline não são executados. Adicionamos um novo item de menu na página de definição de pipeline chamado Problemas de Gatilho, em que você pode saber por que os gatilhos não estão sendo executados. Para acessar esta página, abra o histórico do pipeline. O item de menu Problemas de Gatilho só está disponível para recursos não relacionados ao repositório.

Selecionar Problemas de Gatilho na navegação.

Os gatilhos de recurso podem falhar ao serem executados pelos seguintes motivos.

  • Se a origem da conexão de serviço fornecida for inválida ou se houver erros de sintaxe no gatilho, o gatilho não será configurado, resultando em um erro.

  • Se as condições de gatilho não forem correspondidas, o gatilho não será executado. Um aviso será exibido para que você possa entender por que as condições não foram correspondidas.

    Capacidade de suporte a problemas de gatilho

Próximas etapas

Adicionar e usar grupos de variáveis

Perguntas frequentes

Por que devo usar pipelines resources, em vez do atalho download?

Usar um recurso pipelines é uma maneira de consumir artefatos de um pipeline de CI e também configurar gatilhos automatizados. Um recurso fornece visibilidade total do processo exibindo a versão consumida, os artefatos, as confirmações e os itens de trabalho. Quando você define um recurso do pipeline, os artefatos associados são baixados automaticamente nos trabalhos de implantação.

Você pode optar por baixar os artefatos em trabalhos de build ou substituir o comportamento de download em trabalhos de implantação por download. Para obter mais informações, confira steps.download.

Por que devo usar resources, em vez da tarefa Baixar Artefatos de Pipeline?

Ao usar a tarefa Baixar Artefatos de Pipeline diretamente, você perde a rastreabilidade e os gatilhos. Às vezes, faz sentido usar a tarefa Baixar Artefatos de Pipeline diretamente. Por exemplo, você pode ter uma tarefa de script armazenada em um modelo diferente e a tarefa de script requer que artefatos de um build sejam baixados. Ou talvez você não saiba se alguém que usa um modelo deseja adicionar um recurso do pipeline. Para evitar dependências, você pode usar a tarefa Baixar Artefatos de Pipeline para passar todas as informações de build para uma tarefa.

Como posso disparar uma execução de pipeline, quando minha imagem do Docker Hub for atualizada?

Você precisará configurar um pipeline de lançamento clássico, pois o gatilho de recurso de contêineres não está disponível para Docker Hub para pipelines YAML.

  1. Crie uma nova conexão de serviço do Docker Hub.

  2. Crie um pipeline de lançamento clássico e adicione um artefato do Docker Hub. Defina sua conexão de serviço. Selecione o namespace, o repositório, a versão e o alias de origem.

    Adicionar um artefato do Docker Hub.

  3. Selecione o gatilho e alterne o gatilho de implantação contínua para Habilitar. Você criará uma versão sempre que ocorrer um push do Docker no repositório selecionado.

  4. Crie uma nova fase e um trabalho. Adicione duas tarefas, logon do Docker e Bash:

  • A tarefa do Docker tem a ação login e registra você no Docker Hub.

  • A tarefa Bash executa docker pull <hub-user>/<repo-name>[:<tag>]. Substitua hub-user, repo-name e tag pelos seus valores.

    Adicionar as tarefas logon do Docker e Bash.

Como posso validar e solucionar problemas com webhooks?

  1. Crie uma conexão de serviço.

  2. Referencie sua conexão de serviço e nomeie o webhook na seção webhooks.

    resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias
      connection: MyServiceConnection

  3. Executar o pipeline. Quando você executar o pipeline, o webhook será criado no Azure como uma tarefa distribuída para sua organização.

  4. Execute uma chamada à API POST com o JSON válido no corpo para https://dev.azure.com/{organization}/_apis/public/distributedtask/webhooks/{webhook-name}?api-version={apiversion}. Se você receber uma resposta de código de status 200, o webhook estará pronto para ser consumido pelo pipeline. Se você receber uma resposta de código de status 500 com o erro Cannot find webhook for the given webHookId ..., seu código pode estar em um branch que não seja o branch padrão.

    1. Abra seu pipeline.
    2. Selecione Editar.
    3. Selecione o menu mais ações Selecione o menu mais ações.
    4. Selecione Gatilhos>YAML>Obter Fontes.
    5. Acesse Branch padrão para builds manuais e agendados para atualizar o branch de recurso.
    6. Selecione Salvar & fila.
    7. Depois que esse pipeline for executado com êxito, execute uma chamada à API POST com o JSON válido no corpo para https://dev.azure.com/{organization}/_apis/public/distributedtask/webhooks/{webhook-name}?api-version={apiversion}. Agora você deve receber uma resposta de código de status 200.