Recursos em pipelines YAML

Serviços de DevOps do Azure | Azure DevOps Server | Azure DevOps Server 2022

Este artigo discute recursos para pipelines YAML. Um recurso é algo que um pipeline utiliza e que existe fora desse pipeline. Os recursos nos pipelines YAML podem ser outros pipelines, compilações, contentores, pacotes, repositórios ou webhooks.

Depois de definir um recurso, você pode consumi-lo em qualquer lugar do pipeline. Para obter mais informações e exemplos, consulte Definições de recursos.

resources:
  pipelines:
  - pipeline: resources1
    source: otherPipeline

steps:
- download: resources1
  artifact: artifact1.txt

Você pode usar o estado do recurso para acionar pipelines automaticamente ao definir a trigger propriedade na definição de recurso. O pipeline e as variáveis resources.triggeringAlias e resources.triggeringCategory são então definidos para o nome e a categoria do recurso. Essas variáveis estão vazias, a menos que a Build.Reason variável esteja definida como ResourceTrigger.

Os recursos permitem a rastreabilidade total dos serviços que um pipeline usa, incluindo versão, artefatos, confirmações associadas e itens de trabalho. Se você se inscrever para acionar eventos em seus recursos, poderá automatizar totalmente seus fluxos de trabalho de DevOps.

Autorização de recursos

Os recursos devem ser autorizados a serem utilizados 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 as configurações de administração do recurso para Conceder permissões de acesso a todos os pipelines. Por exemplo, pode gerir ficheiros seguros e grupos de variáveis na página Pipelines Library, e pools de agentes e conexões de serviço em >Pipelines. Essa autorização é conveniente para recursos que você não precisa restringir, como recursos de teste.

• Verifique se você tem pelo menos a função de usuário nas funções de segurança do pool de agentes para seu projeto. Os pipelines YAML criados são automaticamente autorizados a usar recursos onde você tem a função de usuário .

• Se você adicionar uma definição de recurso a um pipeline YAML, mas 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, certifique-se de ter pelo menos a função de usuário no recurso. Em seguida, você pode escolher a opção para autorizar os recursos na compilação com falha. Depois que o recurso for autorizado, você poderá iniciar uma nova compilação.

Verificações de aprovação de recursos

Você pode usar verificações de aprovação e modelos para controlar manualmente o uso de recursos. Usando a verificação de aprovação de modelo necessária, você pode exigir que qualquer pipeline que use um determinado recurso ou ambiente se estenda a partir de um modelo YAML específico.

Definir uma aprovação de modelo necessária aumenta a segurança, garantindo que seu recurso seja usado apenas sob condições específicas. Para obter mais informações, consulte Usar modelos para segurança.

Seletor manual de versão de recursos

O Azure Pipelines avalia as versões padrão para recursos com base em suas definições de recursos. Para execuções agendadas ou execuções manuais se você não escolher manualmente uma execução, o Azure Pipelines considera apenas execuções de integração contínua (CI) concluídas com êxito para avaliar as versões de recursos padrão.

Você pode usar o seletor manual de versão de recursos para escolher diferentes versões de recursos ao acionar manualmente um pipeline de implantação contínua (CD) do YAML. O seletor de versão de recursos é suportado para recursos de pipeline, compilação, repositório, contêiner e pacote.

Para pipeline recursos, o seletor de versão manual permite que você veja todas as execuções disponíveis em todas as ramificações, pesquise as execuções com base no número do pipeline ou ramificação e escolha uma execução bem-sucedida, com falha ou em andamento.

Você não precisa esperar que uma execução de CI seja concluída ou executá-la novamente devido a uma falha não relacionada, antes de poder executar o pipeline de CD. Você tem a flexibilidade de escolher qualquer execução que você sabe que produziu os artefatos que você precisa.

Para usar o seletor de versão de recurso, selecione Recursos no painel Executar pipeline , selecione um recurso e escolha uma versão específica na lista de versões disponíveis. Para recursos em que você não pode buscar versões disponíveis, como pacotes do GitHub, você pode inserir a versão desejada no campo de texto.

Definições de recursos

Os recursos de pipeline do YAML podem ser:

• Outros gasodutos
• Compilações
• Contentores
• Pacotes
• repositórios, ou
• Webhooks.

As seções a seguir fornecem definições e exemplos das categorias de recursos do pipeline YAML. Para obter informações completas sobre o esquema, consulte a definição de recursos na referência de esquema YAML para Pipelines do Azure.

Recurso de pipelines

Você pode usar recursos de CI pipeline como gatilhos para seus fluxos de trabalho de CD. Você também pode fazer referência pipeline a recursos do seu pipeline para baixar artefatos ou usar variáveis de recurso de pipeline. Somente o Azure Pipelines pode usar o pipelines recurso.

Na definição de recurso pipelines

• pipeline é um nome único que se usa para referenciar os recursos do pipeline.
• source é o nome do pipeline que produziu os artefatos dele.

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

Exemplo de definições de recursos de pipeline

A definição de recurso de exemplo a seguir consome artefatos de um pipeline dentro do mesmo projeto do Azure DevOps.

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

Para especificar um pipeline de outro projeto, inclua o project nome na definição de recurso. O exemplo a seguir também usa branch para resolver a versão padrão quando o pipeline é acionado manualmente ou por agendamento. A entrada de ramificação não pode ter curingas.

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

Avaliação da versão do recurso

O Azure Pipelines avalia as versões padrão para recursos com base em suas definições de recursos. As versões de artefato de recurso padrão de um pipeline dependem se o pipeline é executado manualmente ou dentro do cronograma, ou aciona com base no resultado da execução do recurso.

Para uma execução de pipeline manual ou agendada, os valores das propriedades version, branch e tags na definição de recurso definem as versões do artefato. A branch entrada não pode ter curingas e as tags propriedades usam o AND operador.

Para execuções agendadas ou execuções manuais se você não usar o seletor de versão, o Azure Pipelines considera apenas execuções de integração contínua (CI) concluídas com êxito ao avaliar versões de recursos padrão. Para execuções manuais, você pode substituir as versões definidas usando o seletor de versão manual.

A tabela a seguir lista pipeline as propriedades de definição de recursos e as versões de artefato que elas especificam.

A definição de recurso a seguir usa as propriedades pipeline e branch para avaliar a versão padrão quando o pipeline é agendado ou acionado manualmente. A versão dos artefatos myCIAlias é a compilação mais recente executada na ramificação main que tem as tags Production e PreProduction.

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

Gatilhos de recursos de pipeline

Para execuções de pipeline que são iniciadas com base no resultado de uma execução de recurso, as propriedades na definição de recurso determinam as versões de artefato de recurso padrão. Para usar um pipeline recurso como um gatilho para executar o pipeline atual, você deve definir a trigger propriedade. Se não incluir uma propriedade trigger, as execuções de recursos não acionarão as execuções de pipeline atuais.

Quando um pipeline é acionado com base em um valor trigger em uma definição de recurso pipeline, os valores das propriedades version, branch e tags da definição geral de recurso são ignoradas. As trigger propriedades determinam as versões do artefato.

A tabela a seguir descreve como as propriedades trigger afetam o comportamento do gatilho.

O exemplo a seguir mostra uma definição de recurso de pipeline com um simples trigger.

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

O exemplo seguinte mostra um recurso trigger de linha de montagem com condições de ramificação.

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

O exemplo a seguir utiliza os stages filtros para avaliar as condições de gatilho para pipelines de CD. Accionar stages usar o operador AND. O pipeline de CD é acionado logo após a bem-sucedida conclusão de todos os estágios listados.

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

O seguinte exemplo utiliza filtros tags para a avaliação da versão padrão e para o gatilho. As trigger tags usam o AND operador. O tags conjunto nas pipeline definições de recursos é diferente das tags definidas nas ramificações no repositório Git.

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

O seguinte pipeline corre sempre que o pipeline de recursos SmartHotel-CI é executado:

• Funciona em um dos releases ramos ou no main ramo.
• Está marcado com ambos Verified e Signed.
• Conclui tanto a etapa Production como a etapa PreProduction.

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

Download do artefacto de um pipeline

Você pode usar a etapa download num pipeline YAML para descarregar artefatos associados à execução atual ou a outro recurso pipeline.

Os artefatos são baixados automaticamente somente em trabalhos de implantação. Todos os artefatos do pipeline atual e todos os seus pipeline recursos são baixados automaticamente e estão disponíveis no início de cada tarefa de implementação. Você pode substituir esse comportamento definindo download como none, ou especificando outro pipeline identificador de recurso.

Em um trabalho de compilação regular, os artefatos não são baixados automaticamente. Use download explicitamente quando necessário.

Na etapa download, a propriedade opcional artifact especifica os nomes dos artefatos. Se não estiver especificado, todos os artefatos disponíveis serão descarregados.

A propriedade opcional patterns define padrões que representam arquivos para download. 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'

Artefatos do pipeline recurso são transferidos para a pasta $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier>. Para obter mais informações, consulte Publicar e descarregar artefatos de pipeline. Para obter uma maneira alternativa de baixar artefatos de pipeline, consulte Baixar artefatos.

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 recursos

Se você tiver um sistema de compilação de CI que produz artefatos, poderá consumir os artefatos com builds recursos.

A builds categoria é extensível. Um build recurso pode ser de qualquer sistema de CI externo como Jenkins, TeamCity ou CircleCI. Você pode usar builds para escrever uma extensão para consumir artefatos do seu serviço de compilação ou introduzir um novo tipo de serviço.

Na definição build, version tem como padrão a compilação bem-sucedida mais recente. Você deve definir trigger explicitamente, se desejar. Para obter informações completas sobre o esquema, consulte a definição resources.builds.build .

No exemplo a seguir, Jenkins é o tipo de recurso.

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

A tarefa downloadBuild

Os build artefatos de recurso não são baixados automaticamente para jobs/deploy-jobs. Para consumir artefactos do build recurso como parte dos seus trabalhos, é necessário adicionar explicitamente a downloadBuild tarefa. Você pode personalizar o comportamento de download para cada implantação ou trabalho.

A tarefa downloadBuild resolve-se automaticamente para a tarefa de download correspondente ao tipo de recurso que o runtime build define. Artefatos do download do build recurso 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 download do recurso.

A propriedade opcional patterns define um caminho de minimatch ou uma lista de caminhos de minimatch para download. Se estiver em branco, o artefato inteiro será baixado. O exemplo 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 .

Recurso de repositórios

Use a repository palavra-chave para informar o sistema sobre repositórios externos se:

• O seu pipeline tem modelos em outro repositório.
• Você deseja usar checkout do multi-repo com um repositório que requer uma conexão de serviço.

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 tipos de repositório git, github, githubenterprise e 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.

A tabela a seguir descreve os tipos de repository recursos:

Variáveis de recursos 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:
    - 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)"

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

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)"

Comando de checkout para repositórios

Os repositórios do repository recurso não são sincronizados automaticamente nos seus trabalhos. Você pode usar a checkout palavra-chave para buscar um repositório definido em um repository recurso. Para obter mais informações, consulte Consulte vários repositórios no seu pipeline. Para obter informações completas sobre o esquema, consulte a definição steps.checkout .

Recurso de contêineres

Você pode usar containers recursos para consumir imagens de contêiner em seus pipelines de CI/CD. 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 seus trabalhos ou usá-la em trabalhos de contêiner. Se o pipeline exigir o suporte de um ou mais serviços, você também 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, poderá definir um recurso de contêiner genérico sem usar uma type palavra-chave. 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.

Tipo de recurso do Registro de Contêiner do Azure

Para consumir as suas imagens do Registo de Contentores do Azure, pode usar o tipo de recurso de contentor de primeira classe acr. Você pode usar este tipo de recurso nas suas tarefas e para habilitar acionadores automáticos de pipeline.

Você precisa das permissões de Colaborador ou Proprietário do Registro de Contêiner do Azure para usar gatilhos automáticos de pipeline. 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* 

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 recurso 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)

resources:
  packages:
    - package: contoso
      type: npm
      connection: pat-contoso
      name: myname/contoso 
      version: 7.130.88 
      trigger: true

steps:
- getPackage: contoso

resources:
  webhooks:
    - webhook: myWebhookResource
      connection: myWebHookConnection

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

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

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

Rastreabilidade

Azure Pipelines fornece rastreabilidade total para qualquer recurso consumido em um pipeline ou ao nível de uma tarefa de implementação. O Azure Pipelines mostra as seguintes informações para cada execução de pipeline que usa recursos:

• Se um recurso acionou o pipeline, então esse é o recurso que o acionou.
• As versões de recursos e os artefatos consumidos.
• Confirmações associadas a cada recurso.
• Itens de trabalho associados a cada recurso.

Informações de pipeline de CD associadas para pipelines de CI

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

Rastreabilidade de ambiente

Depois de um pipeline ser implementado num ambiente, é possível ver uma lista dos recursos que consumiu, juntamente com os seus commits e itens de trabalho associados.

FAQ

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

A utilização de um recurso pipelines é uma forma 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 atalho download para baixar os artefatos em tarefas de compilação ou para alterar o comportamento de download em tarefas de implementaçã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 lançamento clássico e adicione um artefacto 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 mude a configuração do 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 executa a login ação e efetua o 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 o seu webhook na seção webhooks.

   resources:
     webhooks:
       - webhook: MyWebhookTriggerAlias
         connection: MyServiceConnection
   

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

4. Realize 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 receberes uma resposta com código de status 200, o teu webhook estará pronto para ser utilizado pelo teu 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 o separador YAML e depois escolha Obter origem.
4. Em Ramificação padrão para compilações manuais e agendadas, atualize a sua ramificação de recurso.
5. Selecione Guardar & entrar na fila.
6. Após a execução bem-sucedida deste pipeline, realize uma chamada de API POST com um 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.

Por que meu recurso não funcionou?

Os gatilhos de recursos podem falhar na execução porque:

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

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 não estão disponíveis para recursos do repositório.

Na página Problemas do gatilho, as mensagens de erro e aviso descrevem as razões pelas quais o gatilho falhou.

Conteúdos relacionados

• Sobre recursos para o Azure Pipelines
• Definir variáveis
• Adicionar e usar grupos de variáveis
• Criar e selecionar um ambiente
• Usar o editor de pipeline YAML
• Referência do esquema YAML