Compartilhar via

Recursos em pipelines YAML

  • Artigo

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

Este artigo discute recursos para pipelines YAML. Um recurso é qualquer coisa usada por um pipeline que existe fora do pipeline. Depois de definir um recurso, você pode consumi-lo em qualquer lugar do pipeline.

Os recursos fornecem rastreabilidade completa para os serviços que seu pipeline usa, incluindo a versão, artefatos, confirmações associadas e itens de trabalho. Você pode automatizar totalmente seus fluxos de trabalho de DevOps inscrevendo-se para disparar eventos em seus recursos.

Esquema de recursos

Os recursos em YAML representam fontes de pipelines, builds, repositórios, contêineres, pacotes e webhooks. Para obter informações completas sobre o esquema, consulte a definição de recursos na referência de esquema YAML para Pipelines do Azure.

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

resources.triggeringAlias
resources.triggeringCategory

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

Definição de recursos de pipelines

Se você tiver um pipeline que produz artefatos, poderá consumir os artefatos definindo um recurso pipelines. Somente o Azure Pipelines pode usar o pipelines recurso. Você pode definir gatilhos para seus fluxos de trabalho de implantação contínua (CD) em um recurso de pipeline.

Em sua definição de recurso, pipeline é um valor exclusivo que você pode usar para fazer referência ao recurso de pipeline posteriormente em seu pipeline. O source é o nome do pipeline que produziu o artefato de pipeline. Para obter informações completas sobre o esquema, consulte a definição resources.pipelines.pipeline.

Use o rótulo definido por pipeline para fazer referência ao recurso de pipeline de outras partes do pipeline, como ao usar variáveis de recurso de pipeline ou baixar artefatos. Para obter uma maneira alternativa de baixar artefatos de pipeline, consulte Baixar artefatos.

Importante

Quando você define um gatilho de recurso de pipeline:

  • Se o pipeline recurso for do mesmo repositório que o pipeline atual, ou self, o disparo seguirá a mesma ramificação e confirmação na qual o evento é gerado.
  • Se o recurso de pipeline for de um repositório diferente, o pipeline atual será acionado na ramificação padrão do repositório de pipeline recursos.

Exemplo de definições de recursos de pipeline

O exemplo a seguir consome artefatos de um pipeline dentro do mesmo projeto.

resources:
  pipelines:
  - pipeline: SmartHotel-resource # identifier to use in pipeline resource variables
    source: SmartHotel-CI # name of the pipeline that produces the artifacts

Para consumir um pipeline de outro projeto, inclua o nome do projeto e o nome do código-fonte. O exemplo a seguir usa branch para resolver a versão padrão quando o pipeline é acionado manualmente ou agendado. A entrada de ramificação não pode ter curingas.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    branch: releases/M142

O exemplo a seguir mostra um recurso de pipeline com um gatilho simples.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger: true

O exemplo a seguir mostra um recurso trigger de pipeline com condições de ramificação.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
      - releases/*
      - resources.triggeringAlias

O exemplo a seguir usa stages filtros para avaliar condições de gatilho para pipelines de CD. Os estágios usam o AND operador. Após a conclusão bem-sucedida de todos os estágios fornecidos, o pipeline do CD é acionado.

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:
      - PreProduction
      - Production

O exemplo a seguir usa tags filtros para avaliação de versão padrão e para gatilhos. As tags usam o AND operador.

Os tags são definidos no pipeline de integração contínua (CI) ou CD. Essas tags diferem das tags definidas em ramificações no repositório Git.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    tags: 
    - Production 
    trigger:
      tags:
      - Production
      - Signed

Avaliação da versão do artefato de pipelines

A versão do artefato do pipeline de recursos depende de como o pipeline é acionado.

Gatilho manual ou programado

Se a execução do pipeline for acionada ou agendada manualmente, os valores das propriedades , branche tags definirão a versão do versionartefato. A branch entrada não pode ter curingas. As tags propriedades usam o AND operador.

Propriedades especificadas Versão do artefato
version Os artefatos da compilação que têm o número de execução especificado
branch Os artefatos da compilação mais recente feita na ramificação especificada
tags lista Os artefatos do build mais recente que tem todas as marcas especificadas
Lista branch e tags Os artefatos da compilação mais recente feita na ramificação especificada que tem todas as marcas especificadas
Nenhum Os artefatos do build mais recente em todos os branches

A definição de recurso a seguir pipeline usa as branch propriedades e tags para avaliar a versão padrão quando o pipeline é acionado manualmente ou agendado. Quando você aciona manualmente o pipeline para execução, a versão de artefatos de MyCIAlias pipeline é a compilação mais recente feita na main ramificação que tem as Production marcas e PrepProduction .

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main
    tags:
    - Production
    - PreProduction

Gatilho de conclusão do pipeline de recursos

Quando um pipeline é acionado porque um de seus pipelines de recursos é concluído, a versão dos artefatos é a versão do pipeline de disparo. Os valores das propriedades version, branch e tags são ignorados.

Gatilhos especificados Resultado
branches Uma nova execução de pipeline é acionada sempre que o pipeline de recursos conclui com êxito uma execução em uma das include ramificações.
tags Uma nova execução de pipeline é acionada sempre que o pipeline de recursos conclui com êxito uma execução marcada com todas as marcas especificadas.
stages Uma nova execução de pipeline é acionada sempre que o pipeline de recursos executa com êxito o stages.
branches, tags e stages Uma nova execução de pipeline é acionada sempre que a execução do pipeline de recursos satisfaz todas as condições de ramificação, marcas e estágios.
trigger: true Uma nova execução de pipeline é acionada sempre que o pipeline de recursos conclui uma execução com êxito.
Nenhum Nenhuma nova execução de pipeline é acionada quando o pipeline de recursos conclui uma execução com êxito.

O pipeline a seguir é executado sempre que o pipeline de SmartHotel-CI recursos:

  • É executado em uma das releases filiais ou na main filial
  • É marcado com ambos Verified e Signed
  • Conclui as Production etapas e PreProduction
resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
        include:
        - releases/*
        - main
        exclude:
        - topic/*
      tags: 
      - Verified
      - Signed
      stages:
      - Production
      - PreProduction

Download do artefato de pipeline

A download etapa baixa artefatos associados à execução atual ou a outro recurso de pipeline.

Todos os artefatos do pipeline atual e todos os seus pipeline recursos são baixados automaticamente e disponibilizados no início de cada trabalho de implantação. Você pode substituir esse comportamento definindo download como none, ou especificando outro identificador de recurso de pipeline.

Os artefatos de trabalho regulares não são baixados automaticamente. Use download explicitamente quando necessário.

Os artefatos do recurso são baixados pipeline para o $(PIPELINE. WORKSPACE)/<pasta pipeline-identifier>/<artifact-identifier> . Para obter mais informações, consulte Publicar e baixar artefatos de pipeline.

A propriedade opcional artifact especifica nomes de artefatos. Se não for especificado, todos os artefatos disponíveis serão baixados. A propriedade opcional patterns define padrões que representam arquivos a serem incluídos. Para obter informações completas sobre o esquema, consulte a definição steps.download.

- job: deploy_windows_x86_agent
  steps:
  - download: SmartHotel
    artifact: WebTier1
    patterns: '**/*.zip'

Variáveis de recurso do pipeline

Em cada execução, os metadados de um recurso de pipeline estão disponíveis para todos os trabalhos como variáveis predefinidas. Essas variáveis estão disponíveis para seu pipeline somente em tempo de execução e, portanto, não podem ser usadas em expressões de modelo, que são avaliadas em tempo de compilação do pipeline.

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

O exemplo a seguir retorna os valores de variável predefinidos para o myresourcevars recurso de pipeline.

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)

Cria definição de recurso

Se você tiver um sistema de compilação de CI externo que produza artefatos, poderá consumir artefatos com builds recursos. Um build recurso pode ser de qualquer sistema de CI externo, como Jenkins, TeamCity ou CircleCI.

A builds categoria é extensível. Você pode escrever uma extensão para consumir artefatos do seu serviço de compilação e introduzir um novo tipo de serviço como parte do builds.

build Na definição, version o padrão é a compilação bem-sucedida mais recente. O trigger não está habilitado por padrão e deve ser definido explicitamente. Para obter informações completas sobre o esquema, consulte a definição resources.builds.build.

No exemplo a seguir, Jenkins é o recurso type.

resources:
  builds:
  - build: Spaceworkz
    type: Jenkins
    connection: MyJenkinsServer 
    source: SpaceworkzProj   # name of the Jenkins source project
    trigger: true

Importante

Os gatilhos são suportados para Jenkins hospedados somente onde o Azure DevOps tem linha de visão com o servidor Jenkins.

A tarefa downloadBuild

Os build artefatos de recurso não são baixados automaticamente em seus trabalhos/trabalhos de implantação. Para consumir artefatos do build recurso como parte de seus trabalhos, você precisa adicionar explicitamente a downloadBuild tarefa. Você pode personalizar o comportamento de download para cada implantação ou trabalho.

Essa tarefa é automaticamente resolvida para a tarefa de download correspondente para o tipo de recurso definido pelo tempo de build execução. Os artefatos do recurso são baixados build para o $(PIPELINE. WORKSPACE)/<build-identifier>/ pasta.

downloadBuild Na definição, você especifica o recurso do qual baixar artefatos. A propriedade opcional artifact especifica artefatos para download. Se não for especificado, todos os artefatos associados ao recurso serão baixados.

A propriedade opcional patterns define um caminho de minicorrespondência ou uma lista de caminhos de minicorrespondência para download. Se estiver em branco, todo o artefato será baixado. Por exemplo, o trecho a seguir baixa apenas os arquivos *.zip .

- job: deploy_windows_x86_agent
  steps:
  - downloadBuild: Spaceworkz
    patterns: '**/*.zip'

Para obter informações completas sobre o esquema, consulte a definição steps.downloadBuild.

Definição de recurso do repositório

A palavra-chave repository permite especificar um repositório externo. Você pode usar esse recurso se o pipeline tiver modelos em outro repositório ou se quiser usar o checkout de vários repositórios com um repositório que exija uma conexão de serviço. Você deve informar o sistema sobre esses repositórios.

Por exemplo:

resources:
  repositories:
  - repository: common
    type: github
    name: Contoso/CommonTools
    endpoint: MyContosoServiceConnection

Para obter informações completas sobre o esquema, consulte a definição resources.repositories.repository.

Tipos de recursos do repositório

O Azure Pipelines dá suporte aos seguintes valores para o tipo de repositório: git, github, githubenterprisee bitbucket.

Tipo Valor do nome Exemplo
type: git Outro repositório no mesmo projeto ou na mesma organização. Mesmo projeto: name: otherRepo
Outro projeto na mesma organização: name: otherProject/otherRepo.
type: github Nome completo do repositório do GitHub, incluindo o usuário ou organização. name: Microsoft/vscode
type: githubenterprise Nome completo do repositório do GitHub Enterprise, incluindo o usuário ou a organização. name: Microsoft/vscode
type: bitbucket Nome completo do repositório Bitbucket Cloud, incluindo o usuário ou organização. name: MyBitbucket/vscode

Variáveis de recurso do repositório

Em cada execução, os metadados a seguir para 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ê fornece ao recurso do repositório.

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

O exemplo a seguir tem um recurso de repositório com um alias de , portanto, as variáveis de recurso do commonrepositório são acessadas usando 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)"

Em cada execução, os metadados a seguir para 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ê fornece ao 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

O exemplo a seguir tem um recurso de repositório com um alias de , portanto, as variáveis de recurso do commonrepositório são acessadas usando 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)"

Palavra-chave de checkout para repositórios

Os repositórios do recurso repository não são sincronizados automaticamente nos seus trabalhos. Use a checkout palavra-chave para buscar um repositório definido como parte do repository recurso. Para obter informações completas sobre o esquema, consulte a definição steps.checkout.

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

Definição de recursos de contêineres

Se você precisar consumir imagens de contêiner como parte de seus pipelines de CI/CD, poderá usar containers recursos. Um container recurso pode ser um registro do Docker público ou privado ou uma instância do Registro de Contêiner do Azure.

Você pode consumir uma imagem de recurso de contêiner genérica como parte de seu trabalho ou usar o recurso para trabalhos de contêiner. Se o pipeline exigir o suporte de um ou mais serviços, você precisará criar e se conectar a contêineres de serviço. É possível usar volumes para compartilhar dados entre serviços.

Se você precisar consumir imagens de um registro do Docker como parte de seu pipeline, poderá definir um recurso de contêiner genérico. Nenhuma type palavra-chave é necessária. Por exemplo:

resources:         
  containers:
  - container: smartHotel 
    endpoint: myDockerRegistry
    image: smartHotelApp

Para obter informações completas sobre o esquema, consulte a definição resources.containers.container.

Observação

A enabled: 'true' sintaxe para habilitar gatilhos de contêiner para todas as marcas de imagem é diferente da sintaxe para outros gatilhos de recurso. Certifique-se de usar a sintaxe correta para recursos específicos.

Tipo de recurso do Registro de Contêiner do Azure

Para consumir suas imagens do Registro de Contêiner do Azure, você pode usar o tipo acrde recurso de contêiner de primeira classe . Você pode usar esse tipo de recurso como parte de seus trabalhos e para habilitar gatilhos automáticos de pipeline.

Você precisa de permissões de Colaborador ou Proprietário para o Registro de Contêiner do Azure para usar gatilhos de pipeline automáticos. Para obter mais informações, confira Funções e permissões do Registro de Contêiner do Azure.

Para usar o acr tipo de recurso, você deve especificar os valores , resourceGroupe repository para seu azureSubscriptionregistro de contêiner do Azure. Por exemplo:

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

Observação

Não há suporte para conexões de serviço que usam a federação de identidades de carga de trabalho no azureSubscription.

Variáveis de recurso de contêiner

Depois de definir um contêiner como um recurso, os metadados da imagem do contêiner passam para o pipeline como variáveis. Informações como imagem, registro e detalhes de conexão podem ser acessadas em todos os trabalhos usados em 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. A location variável se aplica somente ao acr tipo de recursos de contêiner.

O exemplo a seguir tem uma conexão de serviço do Gerenciador de Recursos do Azure chamada arm-connection. Para obter mais informações, confira Registros, repositórios e imagens de contêiner do 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)

Definição de recursos de pacotes

Você pode consumir pacotes NuGet e npm GitHub como recursos em pipelines YAML. Para habilitar gatilhos de pipeline automatizados quando uma nova versão do pacote for lançada, defina a trigger propriedade como true.

Ao definir package recursos, especifique o pacote <Repository>/<Name> na name propriedade e defina o pacote type como NuGet ou npm. Para usar pacotes do GitHub, use a autenticação baseada em token de acesso pessoal (PAT) e crie uma conexão de serviço do GitHub que use o PAT.

Para obter informações completas sobre o esquema, consulte a definição resources.packages.package.

Por padrão, os pacotes não são baixados automaticamente nos trabalhos. Para baixar, use getPackage.

O exemplo a seguir tem uma conexão de serviço do GitHub nomeada pat-contoso para um pacote npm do GitHub chamado contoso. Para obter mais informações, confira Pacotes 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

Definição de recursos de Webhooks

Observação

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

Você pode consumir artefatos e habilitar gatilhos automatizados com recursos de pipeline, contêiner, compilação e pacote. No entanto, você não pode usar esses recursos para automatizar suas implantações com base em eventos ou serviços externos.

O webhooks recurso nos pipelines YAML permite que você integre seus pipelines com serviços externos como GitHub, GitHub Enterprise, Nexus e Artifactory para automatizar fluxos de trabalho. Você pode se inscrever em qualquer evento externo por meio de webhooks e usar os eventos para acionar seus pipelines.

Os Webhooks automatizam seu fluxo de trabalho com base em qualquer evento de webhook externo que não seja suportado por recursos de primeira classe, como pipelines, compilações, contêineres ou 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 acionar seus pipelines automaticamente.

Para se inscrever em um evento webhook, defina um recurso webhook em seu pipeline e aponte-o para uma conexão de serviço 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.

Sempre que a conexão de serviço webhook de entrada recebe um evento webhook, uma nova execução é acionada para todos os pipelines inscritos no evento webhook. Você pode consumir os dados de carga JSON em seus trabalhos como variáveis usando o formato ${{ parameters.<WebhookAlias>.<JSONPath>}}.

Para obter informações completas sobre o esquema, consulte a definição resources.webhooks.webhook.

O exemplo a seguir define um recurso webhook:

resources:
  webhooks:
    - webhook: WebHook
      connection: IncomingWH

steps:  
- script: echo ${{ parameters.WebHook.resource.message.title }}

Gatilhos de Webhook

Para configurar gatilhos de webhook, primeiro configure um webhook em seu serviço externo, fornecendo as seguintes informações:

  • URL do pedido: https://dev.azure.com/<Azure DevOps organization>/_apis/public/distributedtask/webhooks/<webhook name>?api-version=6.0-preview
  • Segredo (Opcional): Se você precisar proteger sua carga JSON, forneça um valor secreto.

Em seguida, você cria uma nova conexão de serviço de webhook de entrada. Para esse tipo de conexão de serviço, você define as seguintes informações:

  • Nome do WebHook: O mesmo que o webhook criado em seu serviço externo.
  • Segredo (Opcional): Usado para verificar o hash HMAC-SHA1 da carga útil para verificação da solicitação de entrada. Se você usou um segredo ao criar seu webhook, você deve fornecer o mesmo segredo.
  • Cabeçalho HTTP: O cabeçalho HTTP na solicitação que contém o valor de hash HMAC-SHA1 da carga útil para verificação da solicitação. Por exemplo, o cabeçalho de solicitação do GitHub é X-Hub-Signature.

Captura de tela que mostra a conexão do serviço webhook de entrada.

Para acionar seu pipeline usando um webhook, você faz uma POST solicitação para https://dev.azure.com/<org_name>/_apis/public/distributedtask/webhooks/<webhook_connection_name>?api-version=6.0-preview. Esse ponto de extremidade está disponível publicamente e não precisa de autorização. A solicitação deve ter um corpo como o exemplo a seguir:

{
    "resource": {
        "message": {
            "title": "Hello, world!",
            "subtitle": "I'm using WebHooks!"
        }
    }
}

Observação

O acesso aos dados do corpo da solicitação do webhook pode levar a um YAML incorreto. Por exemplo, a etapa - script: echo ${{ parameters.WebHook.resource.message }} de pipeline puxa toda a mensagem JSON, o que gera YAML inválido. Qualquer pipeline acionado por meio desse webhook não é executado, porque o YAML gerado se tornou inválido.

O trecho a seguir mostra outro exemplo que usa filtros de webhook.

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}}

Seletor de versão manual para recursos

Quando você aciona manualmente um pipeline de CD YAML, o Azure Pipelines avalia automaticamente as versões padrão para os recursos definidos no pipeline, com base nas entradas fornecidas. No entanto, o Azure Pipelines considera apenas execuções de CI concluídas com êxito ao avaliar a versão padrão para gatilhos agendados ou se você não escolher manualmente uma versão.

Você pode usar o seletor de versão do recurso para escolher manualmente uma versão diferente ao criar uma execução. O seletor de versão de recursos é suportado para recursos de pipeline, compilação, repositório, contêiner e pacote.

Para recursos de pipeline, você pode ver todas as execuções disponíveis em todas as ramificações, pesquisá-las com base no número do pipeline ou ramificação e escolher 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 uma execução produziu todos os artefatos necessários. Você não precisa aguardar a conclusão de uma execução de CI ou executá-la novamente devido a uma falha de estágio não relacionada.

Para usar o seletor de versão de recursos, no painel Executar pipeline , selecione Recursos, selecione um recurso e escolha uma versão específica na lista de versões disponíveis.

Captura de tela que mostra o seletor de versão do recurso do repositório.

Para recursos em que você não pode buscar versões disponíveis, como pacotes do GitHub, o seletor de versão fornece um campo de texto para que você possa inserir a versão para a execução escolher.

Autorização de recursos em pipelines YAML

Os recursos devem ser autorizados antes de poderem ser usados em dutos. Os proprietários de recursos controlam os usuários e pipelines que podem acessar seus recursos. Há várias maneiras de autorizar um pipeline YAML a usar recursos.

  • Use a experiência de administração de recursos para autorizar todos os pipelines a acessar o recurso. Por exemplo, grupos de variáveis e arquivos seguros são gerenciados na página Biblioteca em Pipelines, e pools de agentes e conexões de serviço são gerenciados nas configurações do Project. Essa autorização é conveniente se você não precisar restringir o acesso a recursos, como para recursos de teste.

  • Quando você cria um pipeline, todos os recursos referenciados no arquivo YAML são automaticamente autorizados para uso pelo pipeline se você tiver a função Usuário para esses recursos.

  • Se você adicionar um recurso a um arquivo YAML e a compilação falhar com um erro como Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use., você verá uma opção para autorizar os recursos na compilação com falha.

    Se você for membro da função Usuário do recurso, poderá selecionar essa opção e autorizar o recurso na compilação com falha. Depois que o recurso for autorizado, você poderá iniciar uma nova compilação.

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

Verificações de aprovação de recursos

Você pode usar verificações de aprovação e modelos para controlar manualmente quando um recurso é executado. Com a verificação de aprovação de modelo necessária, você pode exigir que qualquer pipeline usando um recurso ou ambiente se estenda de um modelo YAML específico.

A definição de uma aprovação de modelo necessária garante que seu recurso seja usado apenas sob condições específicas e aumenta a segurança. Para saber mais sobre como aprimorar a segurança de pipeline com modelos, consulte Usar modelos para segurança.

Rastreabilidade

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

Rastreabilidade de pipeline

O Azure Pipelines mostra as seguintes informações para cada execução de pipeline:

  • Se um recurso acionou o pipeline, o recurso que disparou o pipeline.
  • A versão do recurso e os artefatos consumidos.
  • Confirmações associadas a cada recurso.
  • 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 inclui recursos consumidos como parte dos trabalhos de implantação e suas confirmações e itens de trabalho associados.

Captura de tela que mostra confirmações em um ambiente.

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

Para fornecer rastreabilidade de ponta a ponta, você pode rastrear quais pipelines de CD consomem um pipeline de CI específico por meio do pipelines recurso. Se outros pipelines consumirem seu pipeline de CI, você verá uma guia Pipelines associados no modo de exibição Executar. A exibição mostra todas as execuções de pipeline de CD YAML que consumiram seu pipeline de CI e os artefatos dele.

Captura de tela que mostra informações de pipelines de CD em um pipeline de CI.

Problemas de gatilho de recursos

Os gatilhos de recursos podem falhar ao serem executados porque:

  • A origem da conexão de serviço fornecida é inválida, há erros de sintaxe no gatilho ou o gatilho não está configurado.
  • As condições de gatilho não são correspondidas.

Para ver por que os gatilhos de pipeline não foram executados, selecione o item de menu Problemas de gatilho na página de definição de pipeline. Problemas de gatilho estão disponíveis apenas para recursos que não são do repositório.

Captura de tela que mostra problemas de gatilho na página principal do pipeline.

Na página Problemas de disparo , as mensagens de erro e aviso descrevem por que o gatilho falhou.

Captura de tela que mostra a capacidade de suporte de problemas do Trigger.

Perguntas frequentes

Quando devo usar os recursos de pipeline, o atalho de download ou a tarefa Baixar artefatos de pipeline?

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 de pipeline, os artefatos associados são baixados automaticamente nos trabalhos de implantação.

Você pode usar o download atalho para baixar os artefatos em trabalhos de compilação ou para substituir o comportamento de download em trabalhos de implantação. Para obter mais informações, consulte a definição steps.download.

A tarefa Baixar artefatos de pipeline não fornece rastreabilidade ou gatilhos, mas às vezes faz sentido usar essa tarefa diretamente. Por exemplo, você pode ter uma tarefa de script armazenada em um modelo diferente que exija que artefatos de uma compilação sejam baixados. Ou, talvez você não queira adicionar um recurso de pipeline a um modelo. 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?

O gatilho de recurso de contêiner não está disponível para pipelines do Docker Hub para YAML, portanto, você precisa configurar um pipeline de versão clássico.

  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 e selecione o namespace, repositório, versão e alias de origem.
  3. Selecione o gatilho e alterne o gatilho de implantação contínua para Habilitar. Cada push do Docker que ocorre no repositório selecionado cria uma versão.
  4. Crie uma nova fase e um trabalho. Adicione duas tarefas, login do Docker e Bash.
    • A tarefa do Docker tem a login ação e conecta você ao Docker Hub.
    • A tarefa Bash executa docker pull <hub-user>/<repo-name>[:<tag>].

Como posso validar e solucionar problemas do meu webhook?

  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. O webhook é 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 uma ramificação que não seja sua ramificação padrão. Para resolver esse problema:

  1. Selecione Editar na página do pipeline.
  2. No menu Mais ações , selecione Disparadores.
  3. Selecione a guia YAML e, em seguida, selecione Obter códigos-fonte.
  4. Em Ramificação padrão para compilações manuais e agendadas, atualize sua ramificação de recurso.
  5. Selecione Salvar & fila.
  6. 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.

Conteúdo relacionado