Recursos em pipelines do YAML

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

Este artigo discute recursos para pipelines do YAML. Um recurso é qualquer coisa que um pipeline usa que existe fora desse pipeline. Os recursos em pipelines YAML podem ser outros pipelines, builds, contêineres, pacotes, repositórios ou webhooks.

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

resources:
  pipelines:
  - pipeline: resources1
    source: otherPipeline

steps:
- download: resources1
  artifact: artifact1.txt

Você pode usar o status do recurso para disparar pipelines automaticamente definindo a trigger propriedade na definição de recurso. O pipeline resources.triggeringAlias e resources.triggeringCategory as variáveis são definidos como o nome e a categoria do recurso. Essas variáveis estão vazias, a menos que a Build.Reason variável seja 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ê assinar eventos de gatilho em seus recursos, poderá automatizar totalmente seus fluxos de trabalho do DevOps.

Autorização de recursos

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

• Use as configurações de administração do recurso para conceder permissões de acesso a todos os pipelines. Por exemplo, você pode gerenciar arquivos seguros e grupos de variáveis na páginaBiblioteca> e pools de agentes e conexões de serviço em Pipelines de configurações>de projeto. 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 do seu projeto. Os pipelines YAML criados são automaticamente autorizados a usar recursos nos quais você tem a função de usuário .

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

Verificações de aprovação para 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 qualquer pipeline que use um determinado recurso ou ambiente para estender de um modelo YAML específico.

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

Seletor de versão de recurso manual

O Azure Pipelines avalia as versões padrão para recursos com base em suas definições de recurso. 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 CI (integração contínua) concluídas com êxito para avaliar as versões de recursos padrão.

Você pode usar o seletor de versão de recurso manual para escolher diferentes versões de recurso ao disparar manualmente um pipeline de CD (implantação contínua) do YAML. O seletor de versão do recurso tem suporte para recursos de pipeline, build, 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 todos os branches, pesquise as execuções com base no número do pipeline ou branch e escolha uma execução bem-sucedida, com falha ou em andamento.

Você não precisa aguardar a conclusão de uma execução de CI 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 necessários.

Para usar o seletor de versão do 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 não é possível buscar versões disponíveis, como pacotes do GitHub, você pode inserir sua versão desejada no campo de texto.

Definições de recurso

Os recursos de pipeline do YAML podem ser:

• Outros pipelines
• Builds
• Contêineres
• Pacotes
• Repositórios ou
• Webhooks.

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

Recurso pipelines

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

Na definição de pipelines recurso:

• pipeline é um nome exclusivo que você usa para referenciar os recursos de pipeline.
• source é o nome do pipeline que produziu os artefatos de pipeline.

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

Exemplo de definições de recurso 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 é disparado manualmente ou por agendamento. A entrada da 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 recurso. As versões de artefato de recurso padrão de um pipeline dependem se o pipeline é executado manualmente ou no agendamento ou dispara com base no resultado da execução do recurso.

Para uma execução de pipeline manual ou agendada, os valores do version, branche tags as propriedades na definição de pipeline recurso definem as versões do artefato. A branch entrada não pode ter caracteres curinga 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 CI (integração contínua) concluída 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 recurso e as versões de artefato especificadas.

A definição de recurso a seguir pipeline usa as branch propriedades e tags a versão padrão quando o pipeline é agendado ou disparado manualmente. A myCIAlias versão de artefatos é a última execução de build no main branch que tem as marcas e Production as PreProduction marcas.

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

Gatilhos de recurso de pipeline

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

Quando um pipeline é disparado com base em um trigger valor em uma pipeline definição de recurso, os valores da definição versionbranchgeral do recurso e tags as propriedades são ignorados. As trigger propriedades determinam as versões do artefato.

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

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

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

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

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

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

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

O exemplo a seguir usa filtros tags para avaliação de versão padrão e para o gatilho. As trigger marcas usam o AND operador. O tags conjunto em pipeline definições de recurso é diferente das marcas definidas em branches no repositório Git.

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

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

• É executado em um dos releases branches ou no main branch.
• É marcado com ambos Verified e Signed.
• Conclui os estágios e Production os PreProduction estágios.

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

Download de artefato de pipeline

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

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 trabalho de implantação. Você pode substituir esse comportamento definindo download como none, ou especificando outro pipeline identificador de recurso.

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

download Na etapa, a propriedade opcional artifact especifica nomes de artefato. 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 baixados. 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 download do pipeline recurso para o $(PIPELINE. WORKSPACE)/<pipeline-identifier>/<artifact-identifier> folder. Para obter mais informações, consulte Publicar e baixar 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)

Compila recurso

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

A categoria builds é extensível. Um recurso build 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 serviço de build ou introduzir um novo tipo de serviço.

Na definição build, o padrão version é a compilação bem-sucedida mais recente. Você deve definir trigger explicitamente se desejado. Para obter informações de esquema completas, 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 em trabalhos/implantação-trabalhos. Para consumir artefatos do recurso build como parte de seus trabalhos, você precisa adicionar explicitamente a tarefa downloadBuild. Você pode personalizar o comportamento de download para cada implantação ou trabalho.

A downloadBuild tarefa é resolvida automaticamente para a tarefa de download correspondente para o tipo de build recurso que o runtime define. Artefatos do download do build recurso para o $(PIPELINE. WORKSPACE)/<build-identifier>/ folder.

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

A propriedade patterns opcional define um caminho de minicorrespondência ou uma lista de caminhos de minicorrespondência a serem baixados. 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 repositórios

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

• Seu pipeline tem modelos em outro repositório.
• Você deseja usar o check-out de vários repositórios 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 de esquema completas, consulte a definição resources.repositories.repository .

Tipos de recurso de repositório

O Azure Pipelines dá suporte aos gittipos , githubgithubenterprisee bitbucket repositório.

• O tipo git refere-se aos repositórios Git do Azure Repos.
• Os repositórios GitHub Enterprise exigem uma conexão de serviço do GitHub Enterprise para autorização.
• Os repositórios Bitbucket Cloud exigem uma conexão de serviço do Bitbucket Cloud para autorização.

A tabela a seguir descreve os repository tipos de recurso:

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

Palavra-chave de checkout para repositórios

Os repositórios do recurso repository 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, confira Fazer check-out de vários repositórios no pipeline. Para obter informações de esquema completas, consulte a definição steps.checkout .

Recurso contêineres

Você pode usar containers recursos para consumir imagens de contêiner em seus pipelines de CI/CD. Um recurso container 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érico 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 se conectar 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 de esquema completas, consulte a definição resources.containers.container .

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 de recurso de contêiner de primeira classe acr. Você pode usar esse tipo de recurso em seus trabalhos e habilitar gatilhos de pipeline automáticos.

Você precisa de permissões de Proprietário ou Colaborador do 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 tipo de recurso acr, você deve especificar os valores azureSubscription, resourceGroup e repository para o 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 de imagem de contêiner são transmitidos para o pipeline como variáveis. Informações como imagem, registro e detalhes de conexão podem ser acessadas em todos os trabalhos usados nas suas tarefas de implantação de contêiner.

As variáveis de recurso de contêiner funcionam com o Docker e o Registro de Contêiner do Azure. Não é possível usar variáveis de recurso de contêiner para contêineres de imagem local. A location variável se aplica somente ao tipo de recurso de acr 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, 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)

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

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

• Se um recurso disparou o pipeline, o recurso que disparou o pipeline.
• As versões de recurso 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 acompanhar quais pipelines de CD consumiram um pipeline de CI específico por meio do pipelines recurso. Se outros pipelines consumirem o 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 YAML de CD que consumiram seu pipeline de CI e os artefatos dele.

Rastreabilidade de ambiente

Depois que um pipeline é implantado em um ambiente, você pode ver uma lista de recursos que ele consumiu e suas confirmações associadas e itens de trabalho.

perguntas frequentes

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

Você pode usar o atalho download para baixar os artefatos em trabalhos de build ou 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 requer que artefatos de um build 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 Hub do Docker 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, 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 Habilitar. Todo push do Docker que ocorre no repositório selecionado cria uma versão.
4. Crie uma nova fase e um trabalho. Adicione duas tarefas, logon do Docker e Bash.
   • A tarefa do Docker tem a ação login e registra você no Docker Hub.
   • A tarefa Bash executa docker pull <hub-user>/<repo-name>[:<tag>].

Como posso validar e solucionar problemas com 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 um branch que não seja o branch padrão. Para resolver esse problema:

1. Selecione Editar em sua página pipeline.
2. No menu Mais ações, selecione Gatilhos.
3. Selecione a guia YAML e, em seguida, Obter fontes.
4. Em Branch padrão para builds manuais e agendados, atualize a ramificação de recurso.
5. Selecione Salvar e colocar na 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.

Por que meu gatilho de recurso não funcionou?

Os gatilhos de recursos podem falhar ao serem executados 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 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 não estão disponíveis para recursos de repositório.

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

Conteúdo relacionado

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