Partilhar via

Recursos em pipelines YAML

  • Artigo

Serviços de DevOps do Azure | 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 total 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 acionar eventos em seus recursos.

Esquema de recursos

Os recursos no YAML representam origens de pipelines, compilações, repositórios, contentores, 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 aciona 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 acionar a execução do pipeline.

Definição de recursos de pipelines

Se você tiver um pipeline que produz artefatos, poderá consumi-los definindo um pipelines recurso. 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 do pipeline. Para obter informações completas sobre o esquema, consulte a definição resources.pipelines.pipeline.

Você usa 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 acionamento segue 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 pipeline repositório de 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 da 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 de 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 nas 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 definirão tags 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 última compilação feita na ramificação especificada
tags Lista Os artefatos da compilação mais recente que tem todas as tags especificadas
branch e tags lista Os artefatos da compilação mais recente feita na ramificação especificada que tem todas as tags especificadas
Nenhuma Os artefatos da última construção em todos os ramos

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 ser executado, a versão dos artefatos do MyCIAlias pipeline é a compilação mais recente feita na main ramificação que tem as Production tags 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 acionamento. Os valores das versionpropriedades , branche são tags 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 tags especificadas.
stages Uma nova execução de pipeline é acionada sempre que o pipeline de recursos executa com êxito o stagesarquivo .
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, tags e estágios.
trigger: true Uma nova execução de pipeline é acionada sempre que o pipeline de recursos conclui uma execução com êxito.
Nenhumas Nenhuma nova execução de pipeline é acionada quando o pipeline de recursos conclui com êxito uma execução.

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

  • Funciona em uma das releases filiais ou na main filial
  • Está marcado com ambos e VerifiedSigned
  • 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 pipeline recurso são baixados para o $(PIPELINE. WORKSPACE)/<pasta pipeline-identifier>/<artifact-identifier> . Para obter mais informações, consulte Publicar e baixar artefatos de pipeline.

A propriedade opcional especifica nomes de artifact 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 de 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, consulte Metadados de recursos de 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áveis predefinidas 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 recursos

Se você tiver um sistema de compilação de CI externo que produz 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

Há suporte para gatilhos para Jenkins hospedados somente quando 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 jobs/deploy-jobs. 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.

Esta tarefa é automaticamente resolvida para a tarefa de download correspondente para o tipo de recurso que o tempo de build execução define. Os artefatos do build recurso são baixados 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 recursos do repositório

A repository palavra-chave permite especificar um repositório externo. Você pode usar esse recurso se seu pipeline tiver modelos em outro repositório ou se quiser usar o check-out multi-repo 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.

  • O git tipo refere-se aos repositórios Git do Azure Repos.
  • Os repositórios do GitHub Enterprise exigem uma conexão de serviço do GitHub Enterprise para autorização.
  • Os repositórios Bitbucket Cloud requerem uma conexão de serviço Bitbucket Cloud para autorização.
Type Valor do nome Exemplo
type: git Outro repositório no mesmo projeto ou mesma organização. Mesmo projeto: name: otherRepo
Outro projeto na mesma organização: name: otherProject/otherRepo.
type: github Nome completo do repositório GitHub, incluindo o usuário ou organização. name: Microsoft/vscode
type: githubenterprise Nome completo do repositório GitHub Enterprise, incluindo o usuário ou 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 recursos do repositório

Em cada execução, os seguintes metadados 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ê dá 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 de 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 seguintes metadados 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ê dá 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 de 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 check-out para repositórios

Os repositórios do repository recurso não são sincronizados automaticamente em 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, consulte Verificar vários repositórios em seu 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 genérica de recurso de contêiner 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 conectar-se a contêineres de serviço. Você pode usar volumes para compartilhar dados entre serviços.

Se você precisar consumir imagens de um registro do Docker como parte do 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.

Nota

A enabled: 'true' sintaxe para habilitar gatilhos de contêiner para todas as tags 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, consulte Funções e permissões do Registro de Contêiner do Azure.

Para usar o acr tipo de recurso, você deve especificar o azureSubscription, resourceGroupe repository valores para seu registro 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*

Nota

As conexões de serviço que usam a federação de identidades de carga de trabalho não são suportadas 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 estão acessíveis 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 locais. 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 Azure Resource Manager chamada arm-connection. Para obter mais informações, consulte 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 em trabalhos. Para fazer o download, use getPackage.

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

Nota

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 em pipelines YAML permite integrar seus pipelines com serviços externos como GitHub, GitHub Enterprise, Nexus e Artifactory para automatizar fluxos de trabalho. Você pode se inscrever em quaisquer eventos externos 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 webhook, com base nos dados de carga JSON para personalizar os gatilhos para 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 de webhook:

resources:
  webhooks:
    - webhook: WebHook
      connection: IncomingWH

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

Gatilhos 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
  • Secreto (Opcional): Se você precisar proteger sua carga JSON útil, 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 no 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 da solicitação do GitHub é X-Hub-Signature.

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

Para acionar seu pipeline usando um webhook, faça uma POST solicitação para https://dev.azure.com/<org_name>/_apis/public/distributedtask/webhooks/<webhook_connection_name>?api-version=6.0-preview. Este 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!"
        }
    }
}

Nota

Acessar dados do corpo de solicitação do webhook pode levar a YAML incorreto. Por exemplo, a etapa - script: echo ${{ parameters.WebHook.resource.message }} de pipeline recebe toda a mensagem JSON, que gera YAML inválido. Qualquer pipeline acionado através deste webhook não é executado, porque o YAML gerado tornou-se 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 manual de versão para recursos

Quando você aciona manualmente um pipeline YAML de CD, 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 de recursos 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 esperar que uma execução de CI seja concluída ou executá-la novamente devido a uma falha de estágio não relacionada.

Para usar o seletor de versão de recurso, 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 de recursos 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 a ser selecionada.

Autorização de recursos em pipelines YAML

Os recursos devem ser autorizados antes de poderem ser usados em gasodutos. 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 para 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 um 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 para seu 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 a partir de um modelo YAML específico.

Definir 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 melhorar a segurança do pipeline com modelos, consulte Usar modelos para segurança.

Rastreabilidade

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

Rastreabilidade de oleodutos

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 que são 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 na visualização Executar . A exibição mostra todas as execuções do pipeline YAML do CD 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 na execução 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 do gatilho , as mensagens de erro e aviso descrevem por que o gatilho falhou.

Captura de tela que mostra a capacidade de suporte a problemas de gatilho.

FAQ

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

Usar um pipelines recurso é uma maneira de consumir artefatos de um pipeline de CI e também configurar gatilhos automatizados. Um recurso oferece visibilidade total do processo, exibindo a versão consumida, artefatos, confirmações e itens de trabalho. Quando você define um recurso de pipeline, os artefatos associados são baixados automaticamente em 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 Download Pipeline Artifacts 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 compilação para uma tarefa.

Como posso acionar uma execução de pipeline quando minha imagem do Docker Hub é atualizada?

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

  1. Crie uma nova conexão de serviço do Docker Hub.
  2. Crie um pipeline de versão clássico e adicione um artefato do Docker Hub. Defina sua conexão de serviço e selecione o namespace, o repositório, a versão e o alias de origem.
  3. Selecione o gatilho e alterne o gatilho de implantação contínua para Ativar. Cada push do Docker que ocorre no repositório selecionado cria uma versão.
  4. Crie um novo estágio e trabalho. Adicione duas tarefas, login no Docker e Bash.
    • A tarefa do Docker tem a login ação e faz login no Docker Hub.
    • A tarefa Bash é executada 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. Faça referência à sua conexão de serviço e nomeie webhooks seu webhook na seção.

    resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias
      connection: MyServiceConnection

  3. Execute os seus pipelines. O webhook é criado no Azure como uma tarefa distribuída para sua organização.

  4. Execute uma chamada de POST API com 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, seu webhook estará pronto para consumo pelo seu 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 é sua ramificação padrão. Para resolver este problema:

  1. Selecione Editar na página do pipeline.
  2. No menu Mais ações , selecione Triggers.
  3. Selecione a guia YAML e, em seguida, selecione Obter fontes.
  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 POST chamada de API com 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údos relacionados