Crie repositórios Bitbucket Cloud

Serviços de DevOps do Azure

O Azure Pipelines pode criar e validar automaticamente cada solicitação pull e confirmar em seu repositório Bitbucket Cloud. Este artigo descreve como configurar a integração entre o Bitbucket Cloud e o Azure Pipelines.

Bitbucket e Azure Pipelines são dois serviços independentes que se integram bem juntos. Seus usuários do Bitbucket Cloud não obtêm acesso automaticamente ao Azure Pipelines. Você deve adicioná-los explicitamente ao Azure Pipelines.

Acesso aos repositórios do Bitbucket

YAML

Você cria um novo pipeline selecionando primeiro um repositório Bitbucket Cloud e, em seguida, um arquivo YAML nesse repositório. O repositório no qual o arquivo YAML está presente é chamado self repositório. Por padrão, esse é o repositório que seu pipeline cria.

Mais tarde, você pode configurar seu pipeline para fazer check-out de um repositório diferente ou de vários repositórios. Para saber como fazer isso, consulte Checkout multi-repo.

Clássico

Você cria um novo pipeline selecionando primeiro Bitbucket Cloud para o tipo de repositório e, em seguida, um dos repositórios aos quais você tem acesso.

Os Pipelines do Azure devem ter acesso aos seus repositórios para buscar o código durante as compilações. Além disso, o usuário que configura o pipeline deve ter acesso de administrador ao Bitbucket, já que essa identidade é usada para registrar um webhook no Bitbucket.

Há 2 tipos de autenticação para conceder acesso ao Azure Pipelines aos seus repositórios Bitbucket Cloud durante a criação de um pipeline.

Authentication type	Os pipelines são executados usando
1. OAuth	A sua identidade Bitbucket pessoal
2. Nome de utilizador e palavra-passe	A sua identidade Bitbucket pessoal

Autenticação OAuth

OAuth é o tipo de autenticação mais simples de começar para repositórios em sua conta Bitbucket. As atualizações de status do Bitbucket serão realizadas em nome de sua identidade pessoal do Bitbucket. Para que os pipelines continuem funcionando, o acesso ao repositório deve permanecer ativo.

Para usar o OAuth, faça login no Bitbucket quando solicitado durante a criação do pipeline. Em seguida, clique em Autorizar para autorizar com OAuth. Uma conexão OAuth será salva em seu projeto de DevOps do Azure para uso posterior, bem como usada no pipeline que está sendo criado.

Nota

O número máximo de repositórios Bitbucket que a interface do usuário dos Serviços de DevOps do Azure pode carregar é 2.000.

Autenticação da palavra-passe

Compilações e atualizações de status do Bitbucket serão realizadas em nome de sua identidade pessoal. Para que as compilações continuem funcionando, o acesso ao repositório deve permanecer ativo.

Para criar uma conexão de senha, visite Conexões de serviço em suas configurações de projeto do Azure DevOps. Crie uma nova conexão de serviço Bitbucket e forneça o nome de usuário e senha para se conectar ao seu repositório Bitbucket Cloud.

Desencadeadores de IC

Os gatilhos de integração contínua (CI) fazem com que um pipeline seja executado sempre que você envia uma atualização para as ramificações especificadas ou envia tags especificadas.

YAML

Os pipelines YAML são configurados por padrão com um gatilho de CI em todas as ramificações, a menos que a configuração Desabilitar gatilho de CI YAML implícito, introduzida no sprint 227 do Azure DevOps, esteja habilitada. A configuração Desabilitar gatilho YAML CI implícito pode ser configurada no nível da organização ou no nível do projeto. Quando a configuração Desabilitar gatilho YAML CI implícito está habilitada, os gatilhos CI para pipelines YAML não são habilitados se o pipeline YAML não tiver uma trigger seção. Por padrão, Desativar gatilho CI YAML implícito não está habilitado.

Ramos

Você pode controlar quais ramificações obtêm gatilhos de CI com uma sintaxe simples:

trigger:
- main
- releases/*

Você pode especificar o nome completo da ramificação (por exemplo, ) ou um curinga (por exemplo, mainreleases/*). Consulte Curingas para obter informações sobre a sintaxe curinga .

Nota

Não é possível usar variáveis em gatilhos, pois as variáveis são avaliadas em tempo de execução (depois que o gatilho é acionado).

Nota

Se você usar modelos para criar arquivos YAML, só poderá especificar gatilhos no arquivo YAML principal para o pipeline. Não é possível especificar gatilhos nos arquivos de modelo.

Para gatilhos mais complexos que usam exclude ou batch, você deve usar a sintaxe completa, conforme mostrado no exemplo a seguir.

# specific branch build
trigger:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

No exemplo acima, o pipeline será acionado se uma alteração for enviada por push para ou para main qualquer ramificação de liberações. No entanto, ele não será acionado se uma alteração for feita em uma ramificação de versões que comece com old.

Se você especificar uma cláusula sem uma exclude include cláusula, isso equivale a especificar * na include cláusula.

Além de especificar nomes de ramificações nas branches listas, você também pode configurar gatilhos com base em tags usando o seguinte formato:

trigger:
  branches:
    include:
      - refs/tags/{tagname}
    exclude:
      - refs/tags/{othertagname}

Se você não especificou nenhum gatilho e a configuração Desabilitar gatilho YAML CI implícito não estiver habilitada, o padrão será como se você tivesse escrito:

trigger:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

Importante

Quando você especifica um gatilho, ele substitui o gatilho implícito padrão e somente os pushes para ramificações explicitamente configuradas para serem incluídas acionarão um pipeline. As inclusões são processadas primeiro e, em seguida, as exclusões são removidas dessa lista.

Execução de CI em lote

Se você tiver muitos membros da equipe carregando alterações com frequência, convém reduzir o número de execuções iniciadas. Se você definir batch como true, quando um pipeline estiver em execução, o sistema aguardará até que a execução seja concluída e, em seguida, iniciará outra execução com todas as alterações que ainda não foram criadas.

# specific branch build with batching
trigger:
  batch: true
  branches:
    include:
    - main

Nota

batch não é suportado em gatilhos de recursos do repositório.

Para esclarecer este exemplo, digamos que um empurrão A para main fez com que o gasoduto acima funcionasse. Enquanto esse pipeline está em execução, envios B adicionais ocorrem no C repositório. Essas atualizações não iniciam novas execuções independentes imediatamente. Mas depois que a primeira execução é concluída, todos os pushes até esse ponto de tempo são agrupados em lote e uma nova execução é iniciada.

Nota

Se o pipeline tiver vários trabalhos e estágios, a primeira execução ainda deverá atingir um estado terminal completando ou ignorando todos os seus trabalhos e estágios antes que a segunda execução possa começar. Por esse motivo, você deve ter cuidado ao usar esse recurso em um pipeline com vários estágios ou aprovações. Se você deseja agrupar suas compilações em lote nesses casos, é recomendável dividir seu processo de CI/CD em dois pipelines - um para compilação (com lote) e outro para implantações.

Caminhos

Você pode especificar caminhos de arquivo para incluir ou excluir.

# specific path build
trigger:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

Ao especificar caminhos, você deve especificar explicitamente ramificações para acionar se estiver usando o Azure DevOps Server 2019.1 ou inferior. Não é possível acionar um pipeline apenas com um filtro de caminho; Você também deve ter um filtro de ramificação e os arquivos alterados que correspondem ao filtro de caminho devem ser de uma ramificação que corresponda ao filtro de ramificação. Se você estiver usando o Azure DevOps Server 2020 ou mais recente, poderá omitir branches o filtro em todas as ramificações em conjunto com o filtro de caminho.

Cartões curinga são suportados para filtros de caminho. Por exemplo, você pode incluir todos os caminhos que correspondem ao src/app/**/myapp*. Você pode usar caracteres curinga (**, , *ou ?) ao especificar filtros de caminho.

• Os caminhos são sempre especificados em relação à raiz do repositório.
• Se você não definir filtros de caminho, a pasta raiz do repositório será implicitamente incluída por padrão.
• Se você excluir um caminho, também não poderá incluí-lo, a menos que o qualifique para uma pasta mais profunda. Por exemplo, se você excluir /tools, poderá incluir /tools/trigger-runs-on-these
• A ordem dos filtros de caminho não importa.
• Os caminhos no Git diferenciam maiúsculas de minúsculas. Certifique-se de usar o mesmo caso que as pastas reais.
• Não é possível usar variáveis em caminhos, pois as variáveis são avaliadas em tempo de execução (após o disparador ter sido acionado).

Nota

Para repositórios do Bitbucket Cloud, usar branches a sintaxe é a única maneira de especificar gatilhos de tag. A tags: sintaxe não é suportada para Bitbucket.

Optar por não participar na IC

Desativando o gatilho de IC

Você pode desativar totalmente os gatilhos de CI especificando trigger: none.

# A pipeline with no CI trigger
trigger: none

Importante

Quando você envia uma alteração para uma ramificação, o arquivo YAML nessa ramificação é avaliado para determinar se uma execução de CI deve ser iniciada.

Clássico

Nota

A variável Build.SourceVersionMessage não funciona com repositórios Bitbucket quando Batch muda enquanto uma compilação está em andamento está habilitada.

Selecione Ativar integração contínua na guia Gatilhos para habilitar esse gatilho se quiser que a compilação seja executada sempre que alguém fizer check-in de código.

Alterações em lote

Marque essa caixa de seleção se você tiver muitos membros da equipe carregando alterações com frequência e quiser reduzir o número de compilações que está executando. Se você selecionar essa opção, quando uma compilação estiver em execução, o sistema aguardará até que a execução seja concluída e, em seguida, enfileirará outra execução de todas as alterações que ainda não foram criadas.

Você pode agrupar alterações em lote e criá-las juntas.

Nota

Se você usar o processamento em lote com um pipeline YAML de vários estágios, uma execução deverá atingir um estado terminal antes que a próxima possa ser iniciada. Isso muitas vezes não é desejável, pois um pipeline de vários estágios pode passar por aprovações e estágios de implantação de longa duração. Nestes casos, recomenda-se que siga uma destas soluções:

• Não utilize lotes
• dividir o pipeline em dois pipelines separados - um para CI e um CD
• definir condições apropriadas nos palcos para ignorá-los e fazer com que uma corrida termine rapidamente

Filtros de ramificação

Você pode especificar as ramificações onde deseja acionar compilações. Se quiser usar caracteres curinga, digite a especificação de ramificação (por exemplo, features/modules/*) e pressione Enter.

Filtros de caminho

Se o repositório Git estiver no Azure Repos ou TFS, você também poderá especificar filtros de caminho para reduzir o conjunto de arquivos que deseja acionar uma compilação.

Sugestões:

• Os caminhos são sempre especificados em relação à raiz do repositório.
• Se você não definir filtros de caminho, a pasta raiz do repositório será implicitamente incluída por padrão.
• Se você excluir um caminho, também não poderá incluí-lo, a menos que o qualifique para uma pasta mais profunda. Por exemplo, se você excluir /tools, poderá incluir /tools/trigger-runs-on-these
• A ordem dos filtros de caminho não importa.
• Os caminhos no Git diferenciam maiúsculas de minúsculas. Certifique-se de usar o mesmo caso que as pastas reais.

Exemplo

Por exemplo, você deseja que sua compilação seja acionada por alterações na main maioria, mas não em todas, das ramificações de recursos. Você também não deseja que as compilações sejam acionadas por alterações em arquivos na pasta de ferramentas.

Ignorando IC para confirmações individuais

Você também pode dizer ao Azure Pipelines para ignorar a execução de um pipeline que um push normalmente acionaria. Basta incluir [skip ci] na mensagem ou descrição qualquer uma das confirmações que fazem parte de um push, e o Azure Pipelines ignorará a execução do CI para esse push. Você também pode usar qualquer uma das seguintes variações.

• [skip ci] ou [ci skip]
• skip-checks: true ou skip-checks:true
• [skip azurepipelines] ou [azurepipelines skip]
• [skip azpipelines] ou [azpipelines skip]
• [skip azp] ou [azp skip]
• ***NO_CI***

Usando o tipo de gatilho em condições

É um cenário comum executar diferentes etapas, trabalhos ou estágios em seu pipeline, dependendo do tipo de gatilho que iniciou a execução. Você pode fazer isso usando a variável Build.Reasonde sistema . Por exemplo, adicione a seguinte condição à sua etapa, trabalho ou estágio para excluí-la das validações de RP.

condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

Comportamento de gatilhos quando novas ramificações são criadas

É comum configurar vários pipelines para o mesmo repositório. Por exemplo, você pode ter um pipeline para criar os documentos para seu aplicativo e outro para criar o código-fonte. Você pode configurar gatilhos de CI com filtros de ramificação e filtros de caminho apropriados em cada um desses pipelines. Por exemplo, você pode querer que um pipeline seja acionado quando você enviar uma atualização por push para a pasta e outro para disparar quando você enviar por push uma atualização para o código do docs aplicativo. Nesses casos, você precisa entender como os pipelines são acionados quando uma nova ramificação é criada.

Aqui está o comportamento quando você envia uma nova ramificação (que corresponde aos filtros de ramificação) para o repositório:

• Se o pipeline tiver filtros de caminho, ele será acionado somente se a nova ramificação tiver alterações em arquivos que correspondam a esse filtro de caminho.
• Se o pipeline não tiver filtros de caminho, ele será acionado mesmo que não haja alterações na nova ramificação.

Carateres universais

Ao especificar uma ramificação, marca ou caminho, você pode usar um nome exato ou um curinga. Os padrões curinga permitem * corresponder a zero ou mais caracteres e corresponder a um único caractere ? .

• Se você iniciar seu padrão com * em um pipeline YAML, deverá envolver o padrão entre aspas, como "*-releases".
• Para ramificações e tags:
  • Um curinga pode aparecer em qualquer lugar no padrão.
• Para caminhos:
  • No Azure DevOps Server 2022 e superior, incluindo os Serviços de DevOps do Azure, um curinga pode aparecer em qualquer lugar dentro de um padrão de caminho e você pode usar * ou ?.
  • No Azure DevOps Server 2020 e inferior, você pode incluir * como o caractere final, mas ele não faz nada diferente de especificar o nome do diretório por si só. Você não pode incluir * no meio de um filtro de caminho e não pode usar ?o .

trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

Gatilhos de RP

Os gatilhos de solicitação pull (PR) fazem com que um pipeline seja executado sempre que uma solicitação pull é aberta com uma das ramificações de destino especificadas ou quando atualizações são feitas para essa solicitação pull.

YAML

Ramos

Você pode especificar as ramificações de destino ao validar suas solicitações pull. Por exemplo, para validar solicitações pull que visam master e releases/*, você pode usar o seguinte pr gatilho.

pr:
- main
- releases/*

Essa configuração inicia uma nova execução na primeira vez que uma nova solicitação pull é criada e após cada atualização feita na solicitação pull.

Você pode especificar o nome completo da ramificação (por exemplo, ) ou um curinga (por exemplo, masterreleases/*).

Nota

Não é possível usar variáveis em gatilhos, pois as variáveis são avaliadas em tempo de execução (depois que o gatilho é acionado).

Nota

Se você usar modelos para criar arquivos YAML, só poderá especificar gatilhos no arquivo YAML principal para o pipeline. Não é possível especificar gatilhos nos arquivos de modelo.

Cada nova execução cria a confirmação mais recente da ramificação de origem da solicitação pull. Isso é diferente de como o Azure Pipelines cria solicitações pull em outros repositórios (por exemplo, Azure Repos ou GitHub), onde cria a confirmação de mesclagem. Infelizmente, o Bitbucket não expõe informações sobre a confirmação de mesclagem, que contém o código mesclado entre as ramificações de origem e destino da solicitação pull.

Se nenhum pr gatilho aparecer no seu arquivo YAML, as validações de solicitação pull serão ativadas automaticamente para todas as ramificações, como se você tivesse escrito o seguinte pr gatilho. Essa configuração dispara uma compilação quando qualquer solicitação pull é criada e quando as confirmações entram na ramificação de origem de qualquer solicitação pull ativa.

pr:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

Importante

Quando você especifica um gatilho, ele substitui o gatilho implícito pr padrão e somente os pushes para ramificações explicitamente configuradas para serem incluídas acionarão um pr pipeline.

Para gatilhos mais complexos que precisam excluir determinadas ramificações, você deve usar a sintaxe completa, conforme mostrado no exemplo a seguir.

# specific branch
pr:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

Caminhos

Você pode especificar caminhos de arquivo para incluir ou excluir. Por exemplo:

# specific path
pr:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

Sugestões:

• Não há suporte para curingas com filtros de caminho.
• Os caminhos são sempre especificados em relação à raiz do repositório.
• Se você não definir filtros de caminho, a pasta raiz do repositório será implicitamente incluída por padrão.
• Se você excluir um caminho, também não poderá incluí-lo, a menos que o qualifique para uma pasta mais profunda. Por exemplo, se você excluir /tools, poderá incluir /tools/trigger-runs-on-these
• A ordem dos filtros de caminho não importa.
• Os caminhos no Git diferenciam maiúsculas de minúsculas. Certifique-se de usar o mesmo caso que as pastas reais.
• Não é possível usar variáveis em caminhos, pois as variáveis são avaliadas em tempo de execução (após o disparador ter sido acionado).

Várias atualizações de RP

Você pode especificar se atualizações adicionais para uma RP devem cancelar execuções de validação em andamento para a mesma RP. A predefinição é true.

# auto cancel false
pr:
  autoCancel: false
  branches:
    include:
    - main

Optar por não participar na validação de RP

Você pode desativar totalmente a validação de solicitação pull especificando pr: none.

# no PR triggers
pr: none

Para obter mais informações, consulte Gatilho PR no esquema YAML.

Nota

Se o pr gatilho não estiver disparando, certifique-se de não ter substituído os gatilhos YAML PR na interface do usuário.

Clássico

Marque o gatilho de validação de solicitação pull e marque a caixa de seleção Habilitar validação de pull request para habilitar compilações em pull requests.

Você pode especificar ramificações para incluir e excluir. Selecione um nome de filial no menu suspenso e selecione Incluir ou Excluir , conforme apropriado. Para ramificações incluídas, uma compilação será acionada em cada push para uma solicitação pull direcionada a essa ramificação.

Execuções informativas

Uma execução informativa informa que o Azure DevOps não conseguiu recuperar o código-fonte de um pipeline YAML. A recuperação do código-fonte acontece em resposta a eventos externos, por exemplo, uma confirmação enviada. Isso também acontece em resposta a gatilhos internos, por exemplo, para verificar se há alterações de código e iniciar uma execução agendada ou não. A recuperação do código-fonte pode falhar por vários motivos, sendo um deles frequente a limitação de solicitações pelo provedor do repositório git. A existência de uma execução informativa não significa necessariamente que o Azure DevOps iria executar o pipeline.

Uma execução informativa se parece com a captura de tela a seguir.

Você pode reconhecer uma execução informacional pelos seguintes atributos:

• O status é Canceled
• A duração é < 1s
• O nome da execução contém um dos seguintes textos:
  • Could not retrieve file content for {file_path} from repository {repo_name} hosted on {host} using commit {commit_sha}.
  • Could not retrieve content for object {commit_sha} from repository {repo_name} hosted on {host}.
  • Could not retrieve the tree object {tree_sha} from the repository {repo_name} hosted on {host}.
  • Could not find {file_path} from repository {repo_name} hosted on {host} using version {commit_sha}. One of the directories in the path contains too many files or subdirectories.
• O nome da execução geralmente contém o erro BitBucket / GitHub que causou a falha na carga do pipeline YAML
• Sem etapas / trabalhos / etapas

Saiba mais sobre execuções informativas.

Limitações

O Azure Pipelines carrega um máximo de 2000 ramificações de um repositório em listas suspensas no Portal de Devops do Azure, por exemplo, na configuração Ramificação padrão para compilações manuais e agendadas ou ao escolher uma ramificação ao executar um pipeline manualmente. Se você não vir a ramificação desejada na lista, digite o nome da ramificação desejada manualmente.

FAQ

Problemas relacionados à integração do Bitbucket se enquadram nas seguintes categorias:

• Gatilhos com falha: Meu pipeline não está sendo acionado quando envio uma atualização para o repositório.
• Versão errada: Meu pipeline é executado, mas está usando uma versão inesperada do source/YAML.

Gatilhos com falha

Acabei de criar um novo pipeline YAML com gatilhos CI/PR, mas o pipeline não está sendo acionado.

Siga cada uma destas etapas para solucionar problemas de seus gatilhos com falha:

• Os gatilhos YAML CI ou PR são substituídos pelas configurações de pipeline na interface do usuário? Ao editar seu pipeline, escolha ... e, em seguida, Triggers.

  

  Verifique a configuração Substituir o gatilho YAML daqui para os tipos de gatilho (Integração contínua ou Validação de solicitação pull) disponíveis para seu repositório.

  

• Webhooks são usados para comunicar atualizações do Bitbucket para o Azure Pipelines. No Bitbucket, navegue até as configurações do seu repositório e, em seguida, para Webhooks. Verifique se os webhooks existem.

• Seu pipeline está pausado ou desativado? Abra o editor do pipeline e selecione Configurações para verificar. Se o pipeline estiver pausado ou desativado, os gatilhos não funcionarão.

• Você atualizou o arquivo YAML na ramificação correta? Se você enviar uma atualização para uma ramificação, o arquivo YAML nessa mesma ramificação governará o comportamento de CI. Se você enviar uma atualização para uma ramificação de origem, o arquivo YAML resultante da mesclagem da ramificação de origem com a ramificação de destino governará o comportamento de RP. Certifique-se de que o arquivo YAML na ramificação correta tem a configuração de CI ou PR necessária.

• Você configurou o gatilho corretamente? Ao definir um gatilho YAML, você pode especificar cláusulas de inclusão e exclusão para ramificações, tags e caminhos. Certifique-se de que a cláusula include corresponda aos detalhes da sua confirmação e que a cláusula de exclusão não os exclua. Verifique a sintaxe dos gatilhos e certifique-se de que está correta.

• Você usou variáveis na definição do gatilho ou dos caminhos? Isso não é apoiado.

• Você usou modelos para o seu arquivo YAML? Em caso afirmativo, certifique-se de que seus gatilhos estão definidos no arquivo YAML principal. Não há suporte para gatilhos definidos dentro de arquivos de modelo.

• Excluiu os ramos ou caminhos para os quais empurrou as suas mudanças? Teste empurrando uma alteração para um caminho incluído em uma ramificação incluída. Observe que os caminhos nos gatilhos diferenciam maiúsculas de minúsculas. Certifique-se de usar o mesmo caso que os de pastas reais ao especificar os caminhos em gatilhos.

• Você acabou de empurrar um novo ramo? Em caso afirmativo, a nova ramificação pode não iniciar uma nova execução. Consulte a seção "Comportamento dos gatilhos quando novas ramificações são criadas".

Meus gatilhos de CI ou RP têm funcionado bem. Mas, eles pararam de trabalhar agora.

Primeiro, siga as etapas de solução de problemas na pergunta anterior. Em seguida, siga estes passos adicionais:

• Tem conflitos de fusão no seu PR? Para um RP que não acionou um pipeline, abra-o e verifique se ele tem um conflito de mesclagem. Resolva o conflito de mesclagem.

• Você está enfrentando um atraso no processamento de eventos push ou PR? Normalmente, você pode verificar isso vendo se o problema é específico de um único pipeline ou é comum a todos os pipelines ou repositórios em seu projeto. Se um push ou uma atualização de RP para qualquer um dos repositórios apresentar esse sintoma, podemos estar enfrentando atrasos no processamento dos eventos de atualização. Verifique se estamos passando por uma interrupção de serviço em nossa página de status. Se a página de status mostrar um problema, nossa equipe já deve ter começado a trabalhar nele. Verifique a página com frequência para atualizações sobre o problema.

Não quero que os usuários substituam a lista de ramificações para gatilhos quando atualizarem o arquivo YAML. Como posso fazê-lo?

Os usuários com permissões para contribuir com código podem atualizar o arquivo YAML e incluir/excluir ramificações adicionais. Como resultado, os usuários podem incluir seu próprio recurso ou ramificação de usuário em seu arquivo YAML e enviar essa atualização para um recurso ou ramificação de usuário. Isso pode fazer com que o pipeline seja acionado para todas as atualizações dessa ramificação. Se você quiser evitar esse comportamento, então você pode:

1. Edite o pipeline na interface do usuário do Azure Pipelines.
2. Navegue até o menu Triggers .
3. Selecione Substituir o gatilho de integração contínua YAML a partir daqui.
4. Especifique as ramificações a serem incluídas ou excluídas para o gatilho.

Quando você segue essas etapas, todos os gatilhos de CI especificados no arquivo YAML são ignorados.

Versão errada

Uma versão errada do arquivo YAML está sendo usada no pipeline. Porquê?

• Para gatilhos de CI, o arquivo YAML que está na ramificação que você está enviando é avaliado para ver se uma compilação de CI deve ser executada.
• Para gatilhos PR, o arquivo YAML resultante da fusão das ramificações de origem e destino do PR é avaliado para ver se uma compilação PR deve ser executada.