Criar repositórios do GitHub

  • Artigo

Azure DevOps Services

O Azure Pipelines pode criar e validar automaticamente cada solicitação de pull e fazer commit do seu repositório do GitHub. Este artigo descreve como configurar a integração entre o GitHub e o Azure Pipelines.

Se você não estiver familiarizado com a integração de pipelines com o GitHub, siga as etapas em Criar seu primeiro pipeline. Volte a este artigo para saber mais sobre como configurar e personalizar a integração entre o GitHub e o Azure Pipelines.

Organizações e usuários

O GitHub e o Azure Pipelines são dois serviços independentes que se integram bem. Cada um deles tem sua própria organização e gerenciamento de usuários. Esta seção faz uma recomendação sobre como replicar a organização e os usuários do GitHub para o Azure Pipelines.

Organizações

A estrutura do GitHub consiste em organização e contas de usuário que contêm repositórios. Confira a documentação do GitHub.

GitHub organization structure

A estrutura do Azure DevOps consiste em organizações que contêm projetos. Confira Planejar sua estrutura organizacional.

Azure DevOps organization structure

O Azure DevOps pode refletir sua estrutura do GitHub com:

  • Uma organização de DevOps para sua organização ou conta de usuário do GitHub
  • DevOps Projects para seus repositórios do GitHub

GitHub structure mapped to Azure DevOps

Para configurar uma estrutura idêntica no Azure DevOps:

  1. Crie uma organização de DevOps com o nome da sua organização ou conta de usuário do GitHub. Ele terá uma URL como https://dev.azure.com/your-organization.
  2. Na organização de DevOps, crie projetos com o nome de seus repositórios. Eles terão URLs como https://dev.azure.com/your-organization/your-repository.
  3. No DevOps Projects, crie pipelines com o nome da organização do GitHub e do repositório que eles criam, como your-organization.your-repository. Em seguida, fica claro para quais repositórios eles servem.

Seguindo esse padrão, os repositórios do GitHub e o Azure DevOps Projects terão caminhos de URL correspondentes. Por exemplo:

Serviço URL
GitHub https://github.com/python/cpython
Azure DevOps https://dev.azure.com/python/cpython

Usuários

Os usuários do GitHub não obtêm acesso automaticamente ao Azure Pipelines. O Azure Pipelines não tem conhecimento das identidades do GitHub. Por esse motivo, não há como configurar o Azure Pipelines para notificar automaticamente os usuários sobre uma falha de build ou uma falha de validação de PR usando sua identidade e endereço de email do GitHub. Você deve criar explicitamente novos usuários no Azure Pipelines para replicar usuários do GitHub. Depois de criar novos usuários, você pode configurar suas permissões no Azure DevOps para refletir suas permissões no GitHub. Você também pode configurar notificações no DevOps usando sua identidade de DevOps.

Funções da organização do GitHub

As funções de membro da organização do GitHub podem ser encontradas em https://github.com/orgs/your-organization/people (substitua your-organization).

As permissões de membro da organização de DevOps podem ser encontradas em https://dev.azure.com/your-organization/_settings/security (substitua your-organization).

As funções em uma organização do GitHub e funções equivalentes em uma organização do Azure DevOps são mostradas abaixo.

Função da organização do GitHub Equivalente à organização do DevOps
Proprietário Membro de Project Collection Administrators
Gerente de cobrança Membro de Project Collection Administrators
Membro Membro de Project Collection Valid Users. Por padrão, o grupo de membros não tem permissão para criar novos projetos. Para alterar a permissão, defina a permissão Create new projects do grupo como Allowou crie um novo grupo com as permissões necessárias.

Funções da conta de usuário do GitHub

Uma conta de usuário do GitHub tem uma função, que é a propriedade da conta.

As permissões de membro da organização de DevOps podem ser encontradas em https://dev.azure.com/your-organization/_settings/security (substitua your-organization).

A função de conta de usuário do GitHub é mapeada para permissões de organização do DevOps da seguinte maneira.

Função da conta de usuário do GitHub Equivalente à organização do DevOps
Proprietário Membro de Project Collection Administrators

Permissões do repositório GitHub

As permissões do repositório GitHub podem ser encontradas em https://github.com/your-organization/your-repository/settings/collaboration (substitua your-organization e your-repository).

As permissões projeto de DevOps podem ser encontradas em https://dev.azure.com/your-organization/your-project/_settings/security (substitua your-organization e your-project).

As permissões equivalentes entre repositórios do GitHub e o Azure DevOps Projects são as seguintes.

Permissão do repositório GitHub Equivalente ao DevOps Projects
Admin Membro de Project Administrators
Gravar Membro de Contributors
Ler Membro de Readers

Se o repositório GitHub conceder permissão às equipes, você poderá criar equipes correspondentes na seção Teams das configurações do Azure DevOps Projects. Em seguida, adicione as equipes aos grupos de segurança acima, assim como os usuários.

Permissões específicas do pipeline

Para conceder permissões a usuários ou equipes para pipelines específicos em um projeto de DevOps, siga estas etapas:

  1. Acesse a página Pipelines do projeto (por exemplo, https://dev.azure.com/your-organization/your-project/_build).
  2. Selecione o pipeline para o qual as permissões específicas devem ser definidas.
  3. No menu de contexto "...", selecione Segurança.
  4. Selecione Adicionar... para adicionar um usuário, equipe ou grupo específico e personalizar suas permissões para o pipeline.

Acesso aos repositórios do GitHub

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

Posteriormente, você pode configurar o pipeline para marcar um repositório diferente ou vários repositórios. Para saber como fazer isso, confira check-out de vários repositórios.

O Azure Pipelines deve ter acesso aos repositórios para disparar seus builds e efetuar fetch do código durante os builds.

Há três tipos de autenticação para conceder acesso do Azure Pipelines aos repositórios do GitHub durante a criação de um pipeline.

Tipo de autenticação Pipelines executados usando Funciona com Verificações do GitHub
1. Aplicativo GitHub A identidade do Azure Pipelines Sim
2. OAuth Sua identidade pessoal do GitHub Não
3. PAT (token de acesso pessoal) Sua identidade pessoal do GitHub Não

Autenticação com aplicativo GitHub

O Aplicativo GitHub do Azure Pipelines é o tipo de autenticação recomendado para pipelines de integração contínua. Depois de instalar o Aplicativo GitHub em sua conta ou organização do GitHub, seu pipeline será executado sem usar sua identidade pessoal do GitHub. Compilações e atualizações de status do GitHub serão executadas usando a identidade do Azure Pipelines. O aplicativo funciona com as Verificações do GitHub para exibir os resultados de build, teste e cobertura de código no GitHub.

Para usar o Aplicativo GitHub, instale-o em sua organização do GitHub ou na conta de usuário para alguns ou todos os repositórios. O Aplicativo GitHub pode ser instalado e desinstalado na home page do aplicativo.

Após a instalação, o Aplicativo GitHub se tornará o método padrão de autenticação do Azure Pipelines no GitHub (em vez de OAuth) quando os pipelines forem criados para os repositórios.

Se você instalar o Aplicativo GitHub para todos os repositórios em uma organização do GitHub, não precisará se preocupar com o envio de emails em massa pelo Azure Pipelines ou a configuração automática de pipelines em seu nome. Como alternativa à instalação do aplicativo para todos os repositórios, os administradores do repositório podem instalá-lo um de cada vez para repositórios individuais. Isso é mais trabalhoso para os administradores, mas não possui vantagens nem desvantagens.

Permissões necessárias no GitHub

A instalação do aplicativo GitHub do Azure Pipelines exige que você seja um proprietário da organização do GitHub ou administrador do repositório. Além disso, para criar um pipeline para um repositório GitHub com gatilhos de solicitação de pull e integração contínua, você deve ter as permissões necessárias do GitHub configuradas. Caso contrário, o repositório não aparecerá na lista de repositórios ao criar um pipeline. Dependendo do tipo de autenticação e da propriedade do repositório, verifique se o acesso apropriado está configurado.

  • Se o repositório estiver em sua conta pessoal do GitHub, instale o Aplicativo GitHub do Azure Pipelines em sua conta pessoal do GitHub e você poderá listar esse repositório ao criar o pipeline no Azure Pipelines.

  • Se o repositório estiver na conta pessoal do GitHub de outra pessoa, a outra pessoa deverá instalar o Aplicativo GitHub do Azure Pipelines em sua conta pessoal do GitHub. Você deve ser adicionado como colaborador nas configurações do repositório em "Colaboradores". Aceite o convite para ser um colaborador usando o link enviado por email para você. Depois de fazer isso, você pode criar um pipeline para esse repositório.

  • Se o repositório estiver em uma organização do GitHub que você possui, instale o Aplicativo GitHub do Azure Pipelines na organização do GitHub. Você também deve ser adicionado como colaborador ou sua equipe deve ser adicionada nas configurações do repositório em "Colaboradores e equipes".

  • Se o repositório estiver em uma organização do GitHub que outra pessoa possui, um proprietário da organização ou administrador do repositório do GitHub deverá instalar o Aplicativo GitHub do Azure Pipelines na organização. Você deve ser adicionado como colaborador ou sua equipe deve ser adicionada nas configurações do repositório em "Colaboradores e equipes". Aceite o convite para ser um colaborador usando o link enviado por email para você.

Permissões de aplicativo do GitHub

O Aplicativo GitHub solicita as seguintes permissões durante a instalação:

Permissão Como o Azure Pipelines usa a permissão
Acesso de gravação ao código Somente após sua ação deliberada, o Azure Pipelines simplificará a criação de um pipeline fazendo commit de um arquivo YAML em um branch selecionado do repositório GitHub.
Acesso de leitura aos metadados O Azure Pipelines recuperará metadados do GitHub para exibir o repositório, branches e problemas associados a um build no resumo do build.
Acesso de leitura e gravação às verificações O Azure Pipelines lerá e gravará seus próprios resultados de cobertura de build, teste e código a serem exibidos no GitHub.
Acesso de leitura e gravação a solicitações de pull Somente após sua ação deliberada, o Azure Pipelines simplificará a criação de um pipeline criando uma solicitação de pull para um arquivo YAML que fez commit em um branch selecionado do repositório GitHub. O Pipelines recupera metadados de solicitação a serem exibidos em resumos de build associados a solicitações de pull.

Solução de problemas na instalação do Aplicativo GitHub

O GitHub pode exibir um erro como:

You do not have permission to modify this app on your-organization. Please contact an Organization Owner.

Isso significa que o Aplicativo GitHub provavelmente já está instalado para sua organização. Quando você cria um pipeline para um repositório na organização, o Aplicativo GitHub será usado automaticamente para se conectar ao GitHub.

Criar pipelines em várias organizações e projetos do Azure DevOps

Depois que o Aplicativo GitHub for instalado, os pipelines poderão ser criados para os repositórios da organização em diferentes organizações e projetos do Azure DevOps. No entanto, se você criar pipelines para um único repositório em várias organizações do Azure DevOps, somente os pipelines da primeira organização poderão ser disparados automaticamente por commits do GitHub ou solicitações de pull. Builds manuais ou agendados ainda são possíveis em organizações secundárias do Azure DevOps.

Autenticação OAuth

O OAuth é o tipo de autenticação mais simples para começar a usar nos repositórios em sua conta pessoal do GitHub. As atualizações de status do GitHub serão executadas em nome de sua identidade pessoal do GitHub. Para que os pipelines continuem funcionando, o acesso ao repositório deve permanecer ativo. Alguns recursos do GitHub, como Verificações, não estão disponíveis com o OAuth e exigem o Aplicativo GitHub.

Para usar o OAuth, selecione Escolher uma conexão diferente abaixo da lista de repositórios ao criar um pipeline. Em seguida, selecione Autorizar para entrar no GitHub e autorizar com o OAuth. Uma conexão OAuth será salva em seu projeto do Azure DevOps para uso posterior e usada no pipeline que está sendo criado.

Permissões necessárias no GitHub

Para criar um pipeline para um repositório GitHub com gatilhos de solicitação de pull e integração contínua, você deve ter as permissões necessárias do GitHub configuradas. Caso contrário, o repositório não aparecerá na lista de repositórios ao criar um pipeline. Dependendo do tipo de autenticação e da propriedade do repositório, verifique se o acesso apropriado está configurado.

  • Se o repositório estiver em sua conta pessoal do GitHub, pelo menos uma vez, autentique-se no GitHub com o OAuth usando suas credenciais pessoais da conta do GitHub. Isso pode ser feito nas configurações do projeto do Azure DevOps em Pipelines > Conexões do serviço > Nova conexão do serviço > GitHub > Autorizar. Conceda ao Azure Pipelines acesso aos seus repositórios em "Permissões" aqui.

  • Se o repositório estiver na conta pessoal do GitHub de outra pessoa, pelo menos uma vez, a outra pessoa deverá se autenticar no GitHub com o OAuth usando suas credenciais pessoais da conta do GitHub. Isso pode ser feito nas configurações do projeto do Azure DevOps em Pipelines > Conexões do serviço > Nova conexão do serviço > GitHub > Autorizar. A outra pessoa deve conceder ao Azure Pipelines acesso aos seus repositórios em "Permissões" aqui. Você deve ser adicionado como colaborador nas configurações do repositório em "Colaboradores". Aceite o convite para ser um colaborador usando o link enviado por email para você.

  • Se o repositório estiver em uma organização do GitHub que você possui, pelo menos uma vez, autentique-se no GitHub com o OAuth usando suas credenciais pessoais da conta do GitHub. Isso pode ser feito nas configurações do projeto do Azure DevOps em Pipelines > Conexões do serviço > Nova conexão do serviço > GitHub > Autorizar. Conceda ao Azure Pipelines acesso à sua organização em "Acesso da organização" aqui. Você deve ser adicionado como colaborador ou sua equipe deve ser adicionada nas configurações do repositório em "Colaboradores e equipes".

  • Se o repositório estiver em uma organização do GitHub que outra pessoa possui, pelo menos uma vez, um proprietário da organização do GitHub deverá se autenticar no GitHub com o OAuth usando suas credenciais pessoais da conta do GitHub. Isso pode ser feito nas configurações do projeto do Azure DevOps em Pipelines > Conexões do serviço > Nova conexão do serviço > GitHub > Autorizar. O proprietário da organização deve conceder ao Azure Pipelines acesso à organização em "Acesso da organização" aqui. Você deve ser adicionado como colaborador ou sua equipe deve ser adicionada nas configurações do repositório em "Colaboradores e equipes". Aceite o convite para ser um colaborador usando o link enviado por email para você.

Revogar o acesso do OAuth

Depois de autorizar o Azure Pipelines a usar o OAuth, para revogá-lo posteriormente e impedir o uso adicional, acesse Aplicativos OAuth em suas configurações do GitHub. Você também pode excluí-lo da lista de conexões de serviço do GitHub em suas configurações de projeto do Azure DevOps.

Autenticação com PAT (token de acesso pessoal)

Os PATs são efetivamente os mesmos que o OAuth, mas permitem controlar quais permissões são concedidas ao Azure Pipelines. As atualizações de status de Builds e do GitHub serão executadas em nome de sua identidade pessoal do GitHub. Para que os builds continuem funcionando, o acesso ao repositório deve permanecer ativo.

Para criar um PAT, acesse Tokens de acesso pessoal em suas configurações do GitHub. As permissões necessárias são repo, admin:repo_hook, read:user e user:email. Essas são as mesmas permissões necessárias ao usar o OAuth acima. Copie o PAT gerado para a área de transferência e cole-o em uma nova conexão de serviço do GitHub nas configurações do projeto do Azure DevOps. Para recall futuro, nomeie a conexão de serviço após o nome de usuário do GitHub. Ele estará disponível em seu projeto do Azure DevOps para uso posterior ao criar pipelines.

Permissões necessárias no GitHub

Para criar um pipeline para um repositório GitHub com gatilhos de solicitação de pull e integração contínua, você deve ter as permissões necessárias do GitHub configuradas. Caso contrário, o repositório não aparecerá na lista de repositórios ao criar um pipeline. Dependendo do tipo de autenticação e da propriedade do repositório, verifique se o acesso a seguir está configurado.

  • Se o repositório estiver em sua conta pessoal do GitHub, o PAT deverá ter os escopos de acesso necessários em Tokens de acesso pessoal: repo, admin:repo_hook, read:user e user:email.

  • Se o repositório estiver na pessoal do GitHub de outra pessoa, o PAT deverá ter os escopos de acesso necessários em Tokens de acesso pessoal: repo, admin:repo_hook, read:user e user:email. Você deve ser adicionado como colaborador nas configurações do repositório em "Colaboradores". Aceite o convite para ser um colaborador usando o link enviado por email para você.

  • Se o repositório estiver em uma organização do GitHub que você possui, o PAT deverá ter os escopos de acesso necessários em Tokens de acesso pessoal: repo, admin:repo_hook, read:user e user:email. Você deve ser adicionado como colaborador ou sua equipe deve ser adicionada nas configurações do repositório em "Colaboradores e equipes".

  • Se o repositório estiver em uma organização do GitHub que outra pessoa possui, o PAT deverá ter os escopos de acesso necessários em Tokens de acesso pessoal: repo, admin:repo_hook, read:user e user:email. Você deve ser adicionado como colaborador ou sua equipe deve ser adicionada nas configurações do repositório em "Colaboradores e equipes". Aceite o convite para ser um colaborador usando o link enviado por email para você.

Revogar o acesso ao PAT

Depois de autorizar o Azure Pipelines a usar um PAT, para excluí-lo posteriormente e impedir o uso adicional, acesse Tokens de acesso pessoal nas configurações do GitHub. Você também pode excluí-lo da lista de conexões de serviço do GitHub em suas configurações de projeto do Azure DevOps.

Gatilhos de CI

Os gatilhos de CI (integração contínua) fazem com que um pipeline seja executado sempre que você envia uma atualização por push para os branches especificados ou envia tags especificadas por push.

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 de gatilho Desabilitar CI YAML implícito, introduzida no Azure DevOps sprint 227, esteja habilitada. A configuração de gatilho Desabilitar CI YAML implícito pode ser definida no nível da organização ou no nível do projeto. Quando a configuração Desabilitar gatilho de CI YAML implícito está habilitada, os gatilhos de CI para pipelines YAML não são habilitados se o pipeline YAML não tem uma seção trigger. Por padrão, Desabilitar gatilho YAML CI implícito não está habilitado.

Branches

Você pode controlar quais branches obtêm gatilhos de CI com uma sintaxe simples:

trigger:
- main
- releases/*

Você pode especificar o nome completo do branch (por exemplo, main) ou um curinga (por exemplo, releases/*). Confira Curingas para obter informações sobre a sintaxe curinga.

Observação

Você não pode usar variáveis em gatilhos, pois as variáveis são avaliadas em runtime (depois que o gatilho é acionado).

Observação

Se você usar modelos para criar arquivos YAML, só poderá especificar gatilhos no arquivo YAML principal para o pipeline. Você não poderá especificar gatilhos nos arquivos de modelo.

Para gatilhos mais complexos que usam exclude ou batch, você precisa 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á disparado se uma alteração for enviada por push para main ou para qualquer branch de versões. No entanto, ele não será disparado se uma alteração for feita em um branch de versões que começa com old.

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

Além de especificar nomes de ramificação nas listas branches, 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 de gatilho Desabilitar YAML CI implícito não está habilitada, o padrão é como se você escrevesse:

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 apenas pushes para branches configurados explicitamente para serem incluídos dispararão um pipeline. As inclusões são processadas primeiro e, em seguida, as exclusões são removidas dessa lista.

Execuções de CI de envio em lote

Se você tiver muitos membros da equipe carregando alterações com frequência, talvez queira 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 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

Observação

batch não é compatível com gatilhos de recursos do repositório.

Para esclarecer este exemplo, digamos que um push A para main causou a execução do pipeline acima. Enquanto esse pipeline está em execução, os pushes adicionais B e C ocorrem no 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.

Observação

Se o pipeline tiver vários trabalhos e fases, a primeira execução ainda deverá atingir um estado terminal concluindo ou ignorando todos os trabalhos e fases dela antes que a segunda execução possa ser iniciada. Por esse motivo, você precisa ter cuidado ao usar esse recurso em um pipeline com várias fases ou aprovações. Se você quiser colocar em lote seus builds nesses casos, é recomendável dividir o processo de CI/CD em dois pipelines : um para build (com envio em lote) e outro para implantações.

Caminhos

Você pode especificar caminhos de arquivo a serem incluídos ou excluídos.

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

Se estiver usando o Azure DevOps Server 2019.1 ou inferior, ao especificar caminhos, você precisará especificar explicitamente branches nos quais disparar. Você não pode disparar um pipeline apenas com um filtro de caminho; você também precisa ter um filtro de branch e os arquivos alterados que correspondem ao filtro de caminho precisam ser de um branch que corresponda ao filtro de branch. Se você estiver usando o Azure DevOps Server 2020 ou mais recente, poderá omitir branches para filtrar em todos os branches em conjunto com o filtro de caminho.

Os curingas são compatíveis com filtros de caminho. Por exemplo, você pode incluir todos os caminhos que correspondem a 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á incluída implicitamente 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. Use a mesma formatação de maiúsculas e minúsculas que as pastas reais.
  • Você não pode usar variáveis em caminhos, pois as variáveis são avaliadas em runtime (depois que o gatilho é acionado).

Marcas

Além de especificar tags nas listas branches, conforme abordado na seção anterior, você pode especificar tags diretamente para incluir ou excluir:

# specific tag
trigger:
  tags:
    include:
    - v2.*
    exclude:
    - v2.0

Se você não especificar nenhum gatilho de tag, por padrão, as tags não dispararão pipelines.

Importante

Se você especificar tags em combinação com filtros de branch, o gatilho será acionado se o filtro de branch for atendido ou o filtro de tag for atendido. Por exemplo, se uma tag enviada por push atender ao filtro de branch, o pipeline será disparado mesmo se a tag for excluída pelo filtro de tag, porque o push atendeu ao filtro de branch.

Recusar a CI

Desabilitar o gatilho de CI

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

# A pipeline with no CI trigger
trigger: none

Importante

Quando você envia uma alteração por push para um branch, o arquivo YAML nesse branch é avaliado para determinar se uma execução de CI deve ser iniciada.

Ignorando a CI para commits individuais

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

  • [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

Executar diferentes etapas, trabalhos ou estágios no pipeline, dependendo do tipo de gatilho que iniciou a execução, é um cenário comum. Você pode fazer isso usando a variável do sistema Build.Reason. Por exemplo, adicione a seguinte condição à etapa, ao trabalho ou à fase para excluí-la das validações de solicitação de pull.

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

Comportamento dos gatilhos quando novos branches são criados

É 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 compilar o código-fonte. Você pode configurar gatilhos de CI com filtros de branch e filtros de caminho apropriados em cada um desses pipelines. Por exemplo, talvez você queira que um pipeline seja disparado ao enviar por push uma atualização para a pasta docs e outra para disparar quando você envia uma atualização por push para o código do aplicativo. Nesses casos, você precisa entender como os pipelines são disparados quando um novo branch é criado.

Aqui está o comportamento quando você envia por push um novo branch (que corresponde aos filtros de branch) para o repositório:

  • Se o pipeline tiver filtros de caminho, ele será disparado somente se o novo branch tiver alterações nos arquivos que correspondam a esse filtro de caminho.
  • Se o pipeline não tiver filtros de caminho, ele será disparado mesmo que não haja alterações no novo branch.

Curingas

Ao especificar um branch, uma tag ou um caminho, você pode usar um nome exato ou um curinga. Os padrões curinga permitem corresponder * a zero ou mais caracteres e ? a um determinado caractere.

  • Se você iniciar seu padrão com * em um pipeline YAML, precisará encapsular o padrão entre aspas, como "*-releases".
  • Para branches e tags:
    • Um curinga pode aparecer em qualquer lugar no padrão.
  • Para caminhos:
    • No Azure DevOps Server 2022 e superior, incluindo o Azure DevOps Services, 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 além de especificar o nome do diretório. Você pode não incluir * no meio de um filtro de caminho e talvez não use ?.
trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

Gatilhos de PR

Gatilhos de PR (solicitação de pull) fazem com que um pipeline seja executado sempre que uma solicitação de pull é aberta com um dos branches de destino especificados ou quando as atualizações são feitas para essa solicitação de pull.

Branches

Você pode especificar os branches de destino ao validar suas solicitações de pull. Por exemplo, para validar as solicitações de pull direcionadas a main e releases/*, você pode usar o gatilho pr a seguir.

pr:
- main
- releases/*

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

Você pode especificar o nome completo do branch (por exemplo, main) ou um curinga (por exemplo, releases/*).

Observação

Você não pode usar variáveis em gatilhos, pois as variáveis são avaliadas em runtime (depois que o gatilho é acionado).

Observação

Se você usar modelos para criar arquivos YAML, só poderá especificar gatilhos no arquivo YAML principal para o pipeline. Você não poderá especificar gatilhos nos arquivos de modelo.

O GitHub cria uma nova referência quando uma solicitação de pull é criada. A referência aponta para um commit de mesclagem, que é o código mesclado entre os branches de origem e de destino da solicitação de pull. O pipeline de validação de PR cria o commit para o qual essa referência aponta. Isso significa que o arquivo YAML usado para executar o pipeline também é uma mesclagem entre o branch de origem e destino. Como resultado, as alterações feitas no arquivo YAML no branch de origem da solicitação de pull podem substituir o comportamento definido pelo arquivo YAML no branch de destino.

Se nenhum gatilho pr aparecer no arquivo YAML, as validações de solicitação de pull serão habilitadas automaticamente para todos os branches, como se você tivesse escrito o gatilho pr a seguir. Essa configuração dispara um build quando qualquer solicitação de pull é criada e quando os commits entram no branch de origem de qualquer solicitação de pull ativa.

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

Importante

Quando você especifica um gatilho pr com um subconjunto de branches, um pipeline é disparado somente quando as atualizações são enviadas por push para esses branches.

Para gatilhos mais complexos que precisam excluir determinados branches, você deve usar a sintaxe completa, conforme mostrado no exemplo a seguir. Neste exemplo, as solicitações de pull são validadas para o destino main ou releases/* e o branch releases/old* é excluído.

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

Caminhos

Você pode especificar caminhos de arquivo a serem incluídos ou excluídos. Por exemplo:

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

Dicas:

  • O Azure Pipelines posta uma status neutro no GitHub quando decide não executar um build de validação devido a uma regra de exclusão de caminho. Isso fornece uma direção clara para o GitHub indicando que o Azure Pipelines concluiu seu processamento. Para obter mais informações, confira Postar o status neutro no GitHub quando um build é ignorado.
  • Agora 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á incluída implicitamente 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. Use a mesma formatação de maiúsculas e minúsculas que as pastas reais.
  • Você não pode usar variáveis em caminhos, pois as variáveis são avaliadas em runtime (depois que o gatilho é acionado).
  • O Azure Pipelines posta uma status neutro no GitHub quando decide não executar um build de validação devido a uma regra de exclusão de caminho.

Várias atualizações de PR

Você pode especificar se mais atualizações para uma PR devem cancelar execuções de validação em andamento para a mesma PR. O padrão é true.

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

Validação de PR de rascunho

Por padrão, os gatilhos de solicitação de pull são acionados em solicitações de pull de rascunho e solicitações de pull que estão prontas para revisão. Para desabilitar gatilhos de solicitação de pull para solicitações de pull de rascunho, defina a propriedade drafts como false.

pr:
  autoCancel: boolean # indicates whether additional pushes to a PR should cancel in-progress runs for the same PR. Defaults to true
  branches:
    include: [ string ] # branch names which will trigger a build
    exclude: [ string ] # branch names which will not
  paths:
    include: [ string ] # file paths which must match to trigger a build
    exclude: [ string ] # file paths which will not trigger a build
  drafts: boolean # whether to build draft PRs, defaults to true

Recusando a validação de PR

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

# no PR triggers
pr: none

Para obter mais informações, confira Gatilho de PR no Esquema YAML.

Observação

Se o gatilho pr não estiver sendo disparado, siga as etapas de solução de problemas nas perguntas frequentes.

Se você tiver uma PR aberta e enviar alterações por push ao branch de origem, vários pipelines poderão ser executados:

  • Os pipelines com um gatilho de PR no branch de destino de PR serão executados no commit de mesclagem (o código mesclado entre os branches de origem e de destino da solicitação de pull), independentemente de existirem commits enviados por push cujas mensagens ou descrições contêm [skip ci] (ou qualquer uma das respectivas variantes).
  • Os pipelines disparados por alterações no branch de origem da PR, se não houver commits enviados por push cujas mensagens ou descrições contêm [skip ci] (ou qualquer uma das respectivas variantes). Se pelo menos um commit enviado por push contiver [skip ci], os pipelines não serão executados.

Por fim, depois de mesclar a PR, o Azure Pipelines executará os pipelines de CI disparados por pushes para o branch de destino se algumas das mensagens ou descrições de commits mesclados não contiverem [skip ci] (ou qualquer uma das respectivas variantes).

Branches protegidos

Você pode executar um build de validação com cada commit ou solicitação de pull direcionada a um branch e até mesmo impedir que as solicitações de pull sejam mescladas até que um build de validação seja bem-sucedido.

Para configurar builds de validação obrigatórios para um repositório GitHub, você deve ser seu proprietário, um colaborador com a função de Administrador ou um membro da organização do GitHub com a função de Gravação.

  1. Primeiro, crie um pipeline para o repositório e compile-o pelo menos uma vez para que seu status seja postado no GitHub, tornando o GitHub ciente do nome do pipeline.

  2. Em seguida, siga a documentação do GitHub para configurar branches protegidos nas configurações do repositório.

    Para verificação de status, selecione o nome do pipeline na lista Verificações de status.

    GitHub pipeline status check

Importante

Se o pipeline não aparecer nesta lista, verifique o seguinte:

Contribuições de fontes externas

Se o repositório do GitHub for de código aberto, você poderá tornar seu projeto do Azure DevOps público para que qualquer pessoa possa exibir os resultados de build, os logs e os resultados do teste do pipeline sem entrar. Quando os usuários fora da sua organização bifurcam seu repositório e enviam solicitações de pull, eles podem exibir o status de builds que validam automaticamente essas solicitações de pull.

Você deve ter em mente as considerações a seguir ao usar o Azure Pipelines em um projeto público ao aceitar contribuições de fontes externas.

Restrições de acesso

Lembre-se das seguintes restrições de acesso ao executar pipelines em projetos públicos do Azure DevOps:

  • Segredos: por padrão, os segredos associados ao pipeline não são disponibilizados para validações de solicitação de pull de bifurcações. Confira Validar contribuições de bifurcações.
  • Acesso entre projetos: todos os pipelines em um projeto público do Azure DevOps são executados com um token de acesso restrito ao projeto. Os pipelines em um projeto público podem acessar recursos como artefatos de build ou resultados de teste somente dentro do projeto, mas não em outros projetos da organização do Azure DevOps.
  • Pacotes do Azure Artifacts: Se os pipelines precisarem de acesso a pacotes do Azure Artifacts, você deverá conceder permissão explicitamente à conta do Serviço de Build do Projeto para acessar os feeds de pacotes.

Contribuições de bifurcações

Importante

Essas configurações afetam a segurança do pipeline.

Quando você cria um pipeline, ele é disparado automaticamente para solicitações de pull de bifurcações do repositório. Você pode alterar esse comportamento, considerando cuidadosamente como ele afeta a segurança. Para habilitar ou desabilitar esse comportamento:

  1. Acesse o projeto do Azure DevOps. Selecione Pipelines, localize seu pipeline e selecione Editar.
  2. Selecione a guia Gatilhos. Depois de habilitar o Gatilho de solicitação de pull, habilite ou desabilite a caixa de seleção Compilar solicitações de pull de bifurcações desse repositório.

Por padrão, com os pipelines do GitHub, os segredos associados ao pipeline de build não são disponibilizadas para builds de solicitação de pull de bifurcações. Esses segredos são habilitados por padrão com pipelines do GitHub Enterprise Server. Os segredos incluem:

Para ignorar essa precaução nos pipelines do GitHub, habilite a caixa de seleção Disponibilizar segredos para builds de bifurcações. Lembre-se do efeito dessa configuração na segurança.

Observação

Quando você habilita compilações de bifurcação para acessar segredos, o Azure Pipelines, por padrão, restringe o token de acesso usado para builds de bifurcação. Ele tem acesso mais limitado a recursos abertos do que um token de acesso normal. Para conceder aos builds de bifurcação as mesmas permissões que as compilações regulares, habilite a configuração Criar builds de bifurcação com as mesmas permissões que as compilações regulares.

Para obter mais informações, consulte Proteção de repositório – Bifurcações.

Você pode definir centralmente como os pipelines compilam PRs de repositórios GitHub bifurcados usando o controle Limitar solicitações de pull de compilação de repositórios GitHub bifurcados. Está disponível no nível da organização e do projeto. Você pode optar por:

  • Desabilitar a compilação de solicitações de pull de repositórios bifurcados
  • Compilar solicitações de pull com segurança de repositórios bifurcados
  • Personalizar regras para compilar solicitações de pull de repositórios bifurcados

Screenshot of centralized control settings for how pipelines build PRs from forked GitHub repositories.

A partir do Sprint 229, para melhorar a segurança dos pipelines, o Azure Pipelines não cria mais pull requests automaticamente de repositórios bifurcados do GitHub. Para novos projetos e organizações, o valor padrão das Pull requests de criação de limite da configuração de repositórios bifurcados do GitHub é Desabilitar a criação de pull requests de repositórios bifurcados.

Quando você escolhe a opção Compilar com segurança solicitações pull de repositórios bifurcados, todos os pipelines, da organização ou de todo o projeto, não podem disponibilizar segredos para compilações de PRs de repositórios bifurcados, não podem fazer com que essas compilações tenham as mesmas permissões que as compilações normais e devem ser acionadas por um comentário de PR. Os projetos ainda podem decidir não permitir que pipelines compilem esses PRs.

Ao escolher a opção Personalizar, você pode definir como restringir as configurações de pipeline. Por exemplo, você pode garantir que todos os pipelines exijam um comentário para compilar uma PR de um repositório GitHub bifurcado, quando a PR pertence a membros que não são da equipe e não são colaboradores. Porém, você pode optar por permitir que eles disponibilizem segredos para tais compilações. Os projetos podem decidir não permitir que pipelines compilem esses PRs ou compile-os com segurança ou tenham configurações ainda mais restritivas do que as especificadas no nível da organização.

O controle está desativado para organizações existentes. A partir de setembro de 2023, novas organizações Compilaram solicitações de pull com segurança de repositórios bifurcados ativados por padrão.

Considerações importantes sobre segurança

Um usuário do GitHub pode bifurcar seu repositório, alterá-lo e criar uma solicitação de pull para propor alterações no repositório. Essa solicitação de pull pode conter código mal-intencionado a ser executado como parte do build disparado. Esse código pode causar danos das seguintes maneiras:

  • Vazar segredos do pipeline. Para atenuar esse risco, não habilite a caixa de seleção Disponibilizar segredos para builds de bifurcações se o repositório for público ou usuários não confiáveis puderem enviar solicitações de pull que disparam compilações automaticamente. Essa opção está desabilitada por padrão.

  • Comprometa o computador que executa o agente para roubar código ou segredos de outros pipelines. Para atenuar isso:

    • Use um pool de agentes hospedado pela Microsoft para criar solicitações de pull de bifurcações. Os computadores de agente hospedados pela Microsoft são excluídos imediatamente após a conclusão de um build, portanto, não haverá impacto duradouro se eles estiverem comprometidos.

    • Se você precisar usar um agente auto-hospedado, não armazene segredos nem execute outras compilações e versões que usem segredos no mesmo agente, a menos que seu repositório seja privado e você confie em criadores de solicitação de pull.

Gatilhos de comentário

Os colaboradores do repositório podem comentar uma solicitação de pull para executar manualmente um pipeline. Aqui estão alguns motivos comuns pelos quais você pode querer fazer isso:

  • Talvez você não queira criar automaticamente solicitações de pull de usuários desconhecidos até que suas alterações possam ser revisadas. Você deseja que um dos membros da equipe examine primeiro o código e execute o pipeline. Isso é comumente usado como uma medida de segurança ao criar código de contribuição de repositórios bifurcados.
  • Talvez você queira executar um conjunto de testes opcional ou mais um build de validação.

Para habilitar gatilhos de comentário, você deve seguir as duas etapas a seguir:

  1. Habilite os gatilhos de solicitação de pull para o pipeline e verifique se você não excluiu o branch de destino.
  2. No portal da Web do Azure Pipelines, edite seu pipeline e escolha Mais ações, Gatilhos. Em seguida, em Validação de solicitação de pull, habilite Exigir o comentário de um membro da equipe antes de criar uma solicitação de pull.
    • Escolha Em todas as solicitações de pull para exigir o comentário de um membro da equipe antes de criar uma solicitação de pull. Com esse fluxo de trabalho, um membro da equipe examina a solicitação de pull e dispara o build com um comentário depois que a solicitação de pull é considerada segura.
    • Escolha Somente em solicitações de pull de não membros da equipe para exigir o comentário de um membro da equipe somente quando uma PR for feita por um membro que não seja da equipe. Nesse fluxo de trabalho, um membro da equipe não precisa da revisão de um membro da equipe secundária para disparar um build.

Com essas duas alterações, o build de validação de solicitação de pull não será disparado automaticamente, a menos que Somente em solicitações de pull de não membros da equipe seja selecionado e a PR seja feita por um membro da equipe. Somente proprietários e colaboradores do repositório com a permissão de "Gravação" podem disparar o build comentando sobre a solicitação de pull com /AzurePipelines run ou /AzurePipelines run <pipeline-name>.

Os seguintes comandos podem ser emitidos para o Azure Pipelines em comentários:

Comando Result
/AzurePipelines help Exibir ajuda para todos os comandos com suporte.
/AzurePipelines help <command-name> Exibir ajuda para o comando especificado.
/AzurePipelines run Executar todos os pipelines associados a esse repositório e cujos gatilhos não excluam essa solicitação de pull.
/AzurePipelines run <pipeline-name> Executar o pipeline especificado, a menos que seus gatilhos excluam essa solicitação de pull.

Observação

Para resumir, você pode comentar usando /azp em vez de /AzurePipelines.

Importante

As respostas a esses comandos aparecerão na discussão da solicitação de pull somente se o pipeline usar o Aplicativo GitHub do Azure Pipelines.

Solucionar problemas de gatilhos de comentário de solicitação de pull

Se você tiver as permissões de repositório necessárias, mas os pipelines não estiverem sendo disparados por seus comentários, verifique se sua associação é pública na organização do repositório ou adicione-se diretamente como um colaborador do repositório. Os pipelines não podem ver membros da organização privada, a menos que sejam colaboradores diretos ou pertençam a uma equipe que seja um colaborador direto. Você pode alterar sua associação à organização do GitHub de privada para pública aqui (substitua Your-Organization pelo nome da sua organização): https://github.com/orgs/Your-Organization/people.

Execuções informativas

Uma execução informativa informa que o Azure DevOps falhou ao recuperar o código-fonte de um pipeline YAML. A recuperação do código-fonte ocorre em resposta a eventos externos; por exemplo, um commit enviado por push. Também acontece em resposta a gatilhos internos; por exemplo, para verificar se há alterações de código e iniciar ou não uma execução agendada. A recuperação do código-fonte pode falhar por vários motivos. Um 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 executaria o pipeline.

Uma execução informativa é semelhante à captura de tela a seguir.

Screenshot of an informational pipeline run.

Você pode reconhecer uma execução informativa 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 do BitBucket/GitHub que causou falha na carga do pipeline YAML
  • Sem estágios/trabalhos/etapas

Saiba mais sobre execuções informativas.

Check-out

Quando um pipeline é disparado, o Azure Pipelines efetua pull do código-fonte do repositório Git do Azure Repos. Você pode controlar vários aspectos de como isso acontece.

Observação

Quando você inclui uma etapa de check-out no pipeline, executamos o seguinte comando: git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1. Se isso não atender às suas necessidades, você poderá optar por excluir o check-out interno por checkout: none e, em seguida, usar uma tarefa de script para executar seu check-out.

Versão preferencial do Git

O agente do Windows vem com uma cópia própria do Git. Se você preferir fornecer seu Git em vez de usar a cópia incluída, defina System.PreferGitFromPath como true. Essa configuração é sempre verdadeira em agentes que não são do Windows.

Caminho de check-out

Se você estiver fazendo check-out de apenas um repositório, por padrão, o check-out do código-fonte será realizado em um diretório chamado s. Para pipelines YAML, você pode alterar isso especificando checkout com um path. O caminho especificado é relativo a $(Agent.BuildDirectory). Por exemplo: se o valor do caminho de check-out for mycustompath e $(Agent.BuildDirectory) for C:\agent\_work\1, o código-fonte será verificado em C:\agent\_work\1\mycustompath.

Se você estiver usando várias etapas checkout, fazendo check-out de vários repositórios e não especificando explicitamente a pasta usando path, cada repositório será colocado em uma subpasta de s com o nome do repositório. Por exemplo, se você marcar dois repositórios chamados tools e code, o check-out do código-fonte será realizado em C:\agent\_work\1\s\tools e C:\agent\_work\1\s\code.

Observe que o valor do caminho de check-out não pode ser definido para subir nenhum nível de diretório acima de $(Agent.BuildDirectory), portanto, path\..\anotherpath resultará em um caminho de check-out válido (ou seja, C:\agent\_work\1\anotherpath), mas o mesmo não ocorrerá para um valor como ..\invalidpath (ou seja, C:\agent\_work\invalidpath).

Você pode definir a configuração path na etapa Check-out do pipeline.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Submódulos

Você poderá definir a configuração submodules na etapa Check-out do pipeline se quiser baixar arquivos de submódulos.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

O pipeline de build fará check-out de seus submódulos do Git, desde que eles sejam de um dos seguintes tipos:

  • Não autenticado: um repositório público não autenticado sem necessidade de credenciais para clonar ou efetuar fetch.

  • Autenticado:

    • contido no mesmo projeto que o repositório Git do Azure Repos especificado acima. As mesmas credenciais usadas pelo agente para obter as fontes do repositório main também são usadas para obter as fontes de submódulos.

    • Adicionado usando uma URL relativa ao repositório main. Por exemplo

      • O check-out deste seria realizado: git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

        Neste exemplo, o submódulo refere-se a um repositório (FabrikamFiber) na mesma organização do Azure DevOps, mas em um projeto diferente (FabrikamFiberProject). As mesmas credenciais usadas pelo agente para obter as fontes do repositório main também são usadas para obter as fontes de submódulos. Isso exige que o token de acesso ao trabalho tenha acesso ao repositório no segundo projeto. Se você tiver restringido o token de acesso ao trabalho, conforme explicado na seção acima, não poderá fazer isso. Você pode permitir que o token de acesso ao trabalho acesse o repositório no segundo projeto, (a) concedendo explicitamente acesso à conta de serviço de build do projeto no segundo projeto ou (b) usando tokens de acesso com escopo de coleção em vez de tokens com escopo de projeto para toda a organização. Para obter mais informações sobre essas opções e as respectivas implicações de segurança, confira Repositórios de acesso, artefatos e outros recursos.

      • O check-out deste não seria realizado: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

Alternativa ao uso da opção Fazer check-out de submódulos

Em alguns casos, você não pode usar a opção Fazer check-out de submódulos. Você pode ter um cenário em que um conjunto diferente de credenciais é necessário para acessar os submódulos. Isso poderá acontecer, por exemplo, se o repositório main e os repositórios de submódulo não forem armazenados na mesma organização do Azure DevOps ou se o token de acesso ao trabalho não tiver acesso ao repositório em um projeto diferente.

Se você não puder usar a opção Fazer checkout de submódulos, poderá usar uma etapa de script personalizada para efetuar fetch de submódulos. Obtenha um PAT (token de acesso pessoal) e prefixe-o com pat:. Depois, codifique essa cadeia de caracteres prefixada em base64 para criar um token de autenticação básico. Por fim, adicione este script ao pipeline:

git -c http.https://<url of submodule repository>.extraheader="AUTHORIZATION: Basic <BASE64_ENCODED_STRING>" submodule update --init --recursive

Substitua "<BASE64_ENCODED_STRING>" pela cadeia de caracteres "pat:token" codificada em Base64.

Use uma variável secreta em seu projeto ou pipeline de build para armazenar o token de autenticação básico gerado. Use essa variável para preencher o segredo no comando Git acima.

Observação

P: Por que não posso usar um gerenciador de credenciais do Git no agente?R: Armazenar as credenciais de submódulo em um gerenciador de credenciais do Git instalado em seu agente de build privado geralmente não é eficaz, pois o gerenciador de credenciais poderá solicitar que você insira novamente as credenciais sempre que o submódulo for atualizado. Isso não é desejável durante builds automatizados, quando a interação do usuário não é possível.

Sincronizar tags

Importante

O recurso de marcas de sincronização tem suporte no Git do Azure Repos com o Azure DevOps Server 2022.1 e superior.

A etapa de check-out usa a opção --tags ao efetuar fetch do conteúdo de um repositório Git. Isso faz com que o servidor efetue fetch de todas as tags, bem como todos os objetos apontados por essas tags. Isso aumenta o tempo para executar a tarefa em um pipeline, especialmente se você tiver um repositório grande com várias tags. Além disso, a etapa de check-out sincroniza tags mesmo quando você habilita a opção de fetch superficial, anulando a utilidade dela. Para reduzir a quantidade de dados buscados ou extraídos de um repositório Git, a Microsoft adicionou uma nova opção de check-out para controlar o comportamento das tags de sincronização. Essa opção está disponível em pipelines clássicos e YAML.

Se as tags devem ou não ser sincronizadas ao fazer check-out de um repositório é algo que pode ser configurado no YAML pela definição da propriedade fetchTags e na interface do usuário pela configuração Sincronizar tags.

Você pode definir a configuração fetchTags na etapa Check-out do pipeline.

Para definir a configuração no YAML, defina a propriedade fetchTags.

steps:
- checkout: self
  fetchTags: true

Você também pode definir essa configuração usando a opção Sincronizar tags na interface do usuário das configurações do pipeline.

  1. Edite seu pipeline YAML e escolha Mais ações, Gatilhos.

    Screenshot of more triggers menu.

  2. Escolha YAML, Obter fontes.

    Screenshot of Get sources.

  3. Defina a configuração Sincronizar tags.

    Screenshot of Sync tags setting.

Observação

Se você definir fetchTags explicitamente em sua etapa checkout, essa configuração terá prioridade sobre a configuração definida na interface do usuário das configurações do pipeline.

Comportamento padrão

  • Para pipelines existentes criados antes do lançamento do Azure DevOps sprint 209, lançado em setembro de 2022, o padrão para sincronizar marcas permanece o mesmo que o comportamento existente antes da adição das opções Sincronizar tags, que é true.
  • Para novos pipelines criados após a versão 209 do Azure DevOps sprint, o padrão para sincronizar tags é false.

Observação

Se você definir fetchTags explicitamente em sua etapa checkout, essa configuração terá prioridade sobre a configuração definida na interface do usuário das configurações do pipeline.

Fetch superficial

Talvez você queira limitar de quão anteriormente o histórico deve ser baixado. Efetivamente, isso resulta em git fetch --depth=n. Se o repositório for grande, essa opção poderá tornar o pipeline de build mais eficiente. Seu repositório poderá ser grande se estiver em uso por um longo tempo e tiver um histórico considerável. Também poderá ser grande se você tiver adicionado e excluído arquivos grandes posteriormente.

Importante

Novos pipelines criados após a atualização do Azure DevOps sprint 209 de setembro de 2022 têm o fetch superficial habilitado por padrão e configurado com uma profundidade de 1. Anteriormente, o padrão não era efetuar fetch superficialmente. Para verificar seu pipeline, exiba a configuração Fetch superficial na interface do usuário das configurações do pipeline, conforme descrito na seção a seguir.

Você pode definir a configuração fetchDepth na etapa Check-out do pipeline.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Você também pode configurar a profundidade do fetch definindo a opção Profundidade superficial na interface do usuário das configurações do pipeline.

  1. Edite seu pipeline YAML e escolha Mais ações, Gatilhos.

    Screenshot of more triggers menu.

  2. Escolha YAML, Obter fontes.

    Screenshot of Get sources.

  3. Defina a configuração Fetch superficial. Desmarque Fetch superficial para desabilitar o fetch superficial ou marque a caixa e insira uma Profundidade para habilitar o fetch superficial.

    Screenshot of options.

Observação

Se você definir fetchDepth explicitamente em sua etapa checkout, essa configuração terá prioridade sobre a configuração definida na interface do usuário das configurações do pipeline. A configuração de fetchDepth: 0 efetua fetch de todo o histórico e substitui a configuração Fetch superficial.

Nesses casos, essa opção pode ajudar você a conservar recursos de rede e armazenamento. Ela também pode economizar tempo. O motivo pelo qual ela nem sempre economiza tempo é porque, em algumas situações, o servidor pode precisar gastar tempo calculando os commits a serem baixados para obter a profundidade especificada.

Observação

Quando o pipeline é iniciado, o branch a ser compilado é resolvido para uma ID de commit. Em seguida, o agente busca o branch e faz check-out do commit desejado. Há uma pequena janela entre quando um branch é resolvido para uma ID do commit e quando o agente executa o check-out. Se o branch for atualizado rapidamente e você definir um valor muito pequeno para fetch superficial, o commit poderá não existir quando o agente tentar fazer check-out dele. Se isso acontecer, aumente a configuração de profundidade de busca superficial.

Não sincronizar fontes

Talvez você queira ignorar o fetch de novos commits. Essa opção pode ser útil em casos em que você deseja:

  • Usar git init, config e fetch usando suas opções personalizadas.

  • Usar um pipeline de build para executar apenas a automação (por exemplo, alguns scripts) que não dependem do código no controle de versão.

Você pode definir a configuração Não sincronizar fontes na etapa Check-out do pipeline definindo checkout: none.

steps:
- checkout: none  # Don't sync sources

Observação

Quando você usa essa opção, o agente também ignora a execução de comandos Git que limpam o repositório.

Limpar build

Você pode executar diferentes formas de limpeza do diretório de trabalho do agente auto-hospedado antes que um build seja executado.

Em geral, para obter um desempenho mais rápido de seus agentes auto-hospedados, não limpe o repositório. Nesse caso, para obter o melhor desempenho, verifique se você também está compilando incrementalmente, desabilitando qualquer opção Limpar da tarefa ou ferramenta que você está usando para compilar.

Se você precisar limpar o repositório (por exemplo, para evitar problemas causados por arquivos residuais de uma compilação anterior), suas opções para isso são descritas abaixo.

Observação

A limpeza não será eficaz se você estiver usando um agente hospedado pela Microsoft, pois você receberá um novo agente todas as vezes.

Você pode definir a configuração clean na etapa Check-out do pipeline.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Quando clean é definido como true, o pipeline de build desfaz eventuais alterações em $(Build.SourcesDirectory). Mais especificamente, os comandos Git a seguir são executados antes de efetuar fetch da fonte.

git clean -ffdx
git reset --hard HEAD

Para obter mais opções, você pode definir a configuração workspace de um Trabalho.

jobs:
- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  ...
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

Isso fornece as opções de limpeza a seguir.

  • outputs: a mesma operação que a configuração clean descrita na tarefa de check-out anterior e que, além disso, exclui e recria $(Build.BinariesDirectory). Observe que o $(Build.ArtifactStagingDirectory) e $(Common.TestResultsDirectory) são sempre excluídos e recriados antes de cada build, independentemente de qualquer uma dessas configurações.

  • resources: exclui e recria $(Build.SourcesDirectory). Isso resulta na inicialização de um novo repositório Git local para cada build.

  • all: exclui e recria $(Agent.BuildDirectory). Isso resulta na inicialização de um novo repositório Git local para cada build.

Fontes de rótulo

Talvez você queira rotular seus arquivos de código-fonte para permitir que sua equipe identifique facilmente qual versão de cada arquivo está incluída no build concluído. Você também tem a opção de especificar se o código-fonte deve ser rotulado para todos os builds ou apenas para builds bem-sucedidos.

No momento, não é possível definir essa configuração no YAML, mas você pode fazer isso no editor clássico. Ao editar um pipeline YAML, você pode acessar o editor clássico escolhendo Gatilhos no menu do editor YAML.

Configure Git options, YAML.

No editor clássico, escolha YAML, escolha a tarefa Obter fontes e configure lá as propriedades desejadas.

From the Classic editor, choose YAML > Get sources.

Em Formato de tag, você pode usar variáveis definidas pelo usuário e predefinidas que têm um escopo de "Todos". Por exemplo:

$(Build.DefinitionName)_$(Build.DefinitionVersion)_$(Build.BuildId)_$(Build.BuildNumber)_$(My.Variable)

As quatro primeiras variáveis são predefinidas. My.Variable pode ser definido por você na guia variáveis.

O pipeline de build rotula suas fontes com uma Tag do git.

Algumas variáveis de build podem produzir um valor que não é um rótulo válido. Por exemplo, variáveis como $(Build.RequestedFor) e $(Build.DefinitionName) podem conter um espaço em branco. Se o valor contiver um espaço em branco, a marca não será criada.

Depois que as fontes são marcadas pelo pipeline de build, um artefato do Git com a referência refs/tags/{tag} é adicionado automaticamente ao build concluído. Isso oferece à sua equipe rastreabilidade adicional e uma maneira mais amigável de navegar do build para o código que foi compilado. A tag é considerada um artefato de build, pois é produzida pelo build. Quando o build é excluído manualmente ou por meio de uma política de retenção, a tag também é excluída.

Variáveis predefinidas

Quando você cria um repositório GitHub, a maioria das variáveis predefinidas está disponível para seus trabalhos. No entanto, como o Azure Pipelines não reconhece a identidade de um usuário que está fazendo uma atualização no GitHub, as seguintes variáveis são definidas como identidade do sistema em vez de identidade do usuário:

  • Build.RequestedFor
  • Build.RequestedForId
  • Build.RequestedForEmail

Atualizações de status

Há dois tipos de status que o Azure Pipelines posta de volta no GitHub: status básicos e Execuções de Verificação do GitHub. A funcionalidade de Verificações do GitHub só está disponível com os Aplicativos GitHub.

Os status do pipeline aparecem em vários locais na interface do usuário do GitHub.

  • Para PRs, eles são exibidos na guia Conversas de PR.
  • Para commits individuais, eles são exibidos ao passar o mouse sobre a marca status após o tempo de commit na guia commits do repositório.

Conexões do GitHub PAT ou OAuth

Para pipelines que usam conexões PAT ou OAuth do GitHub, os status são postados novamente no commit/PR que disparou a execução. A API de status do GitHub é usada para postar essas atualizações. Esses status contêm informações limitadas: status de pipeline (falha, êxito), URL para vincular de volta ao pipeline de build e uma breve descrição do status.

Os status das conexões PAT ou OAuth do GitHub são enviados apenas no nível de execução. Em outras palavras, você pode ter um único status atualizado para uma execução inteira. Se você tiver vários trabalhos em uma execução, não poderá postar um status separado para cada trabalho. No entanto, vários pipelines podem postar status separados no mesmo commit.

Verificações do GitHub

Para pipelines configurados usando o aplicativo GitHub do Azure Pipelines, o status é postado novamente na forma de Verificações do GitHub. As Verificações do GitHub permitem enviar informações detalhadas sobre o status e teste do pipeline, cobertura de código e erros. A API de Verificações do GitHub pode ser encontrada aqui.

Para cada pipeline que usa o Aplicativo GitHub, as verificações são postadas novamente para a execução geral e cada trabalho nessa execução.

O GitHub permite três opções quando uma ou mais Execuções de Verificação falham em uma PR/commit. Você pode optar por "executar novamente" a Verificação individual, executar novamente todas as Verificações com falha nessa PR/commit ou executar novamente todas as Verificações, independentemente de terem sido bem-sucedidas inicialmente ou não.

GitHub checks rerun

Clicar no link "Executar novamente" ao lado do nome Verificar execução resultará na repetição da execução do Azure Pipelines que gerou a Execução de Verificação. A execução resultante terá o mesmo número de execução e usará a mesma versão do código-fonte, configuração e arquivo YAML que o build inicial. Somente os trabalhos que falharam na execução inicial e quaisquer trabalhos downstream dependentes serão executados novamente. Clicar no link "Executar novamente todas as verificações com falha" terá o mesmo efeito. Esse é o mesmo comportamento que clicar em "Executar novamente" na interface do usuário do Azure Pipelines. Clicar em "Executar todas as verificações novamente" resultará em uma nova execução, com um novo número de execução e obterá alterações na configuração ou no arquivo YAML.

Limitações

  • Para obter o melhor desempenho, recomendamos um máximo de 50 pipelines em um único repositório. Para um desempenho aceitável, recomendamos um máximo de 100 pipelines em um único repositório. O tempo necessário para processar um push em um repositório aumenta com o número de pipelines nesse repositório. Sempre que houver envio por push para um repositório, o Azure Pipelines precisará carregar todos os pipelines YAML nesse repositório para descobrir se algum deles precisa ser executado, e carregar cada pipeline causa problemas no desempenho. Além dos problemas de desempenho, ter muitos pipelines em um único repositório pode levar à limitação do lado do GitHub, já que o Azure Pipelines pode fazer muitas solicitações em um curto período de tempo.
  • O uso de modelos de extensão e inclusão em um pipeline afeta a taxa na qual o Azure Pipelines faz solicitações de API do GitHub e pode levar à limitação do lado do GitHub. Antes de executar um pipeline, o Azure Pipelines precisa gerar o código YAML completo; portanto, ele precisa buscar todos os arquivos de modelo.
  • O Azure Pipelines carrega um máximo de 2000 ramificações de um repositório nas 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.

Perguntas frequentes

Os problemas relacionados à integração do GitHub se enquadram nas seguintes categorias:

  • Tipos de conexão: não sei qual tipo de conexão estou usando para conectar meu pipeline ao GitHub.
  • Gatilhos com falha: meu pipeline não está sendo disparado quando efetuo push de uma atualização para o repositório.
  • Check-out com falha: meu pipeline está sendo disparado, mas ele falha na etapa de check-out.
  • Versão errada: meu pipeline é executado, mas está usando uma versão inesperada da fonte/YAML.
  • Atualizações de status ausentes: meus PRs do GitHub estão bloqueados porque o Azure Pipelines não reportou uma atualização status.

Tipos de conexão

Para solucionar problemas de gatilhos, como saber o tipo de conexão do GitHub que estou usando para meu pipeline?

A solução de problemas com gatilhos depende muito do tipo de conexão do GitHub que você usa em seu pipeline. Há duas maneiras de determinar o tipo de conexão: no GitHub e no Azure Pipelines.

  • No GitHub: se um repositório estiver configurado para usar o aplicativo GitHub, os status em PRs e commits serão Verificar Execuções. Se o repositório tiver o Azure Pipelines configurado com conexões OAuth ou PAT, os status serão o estilo "antigo" de status. Uma maneira rápida de determinar se os status são Verificar Execuções ou status simples é examinar a guia "conversa" em uma PR do GitHub.

    • Se o link "Detalhes" redirecionar para a guia Verificações, ele será uma Execução de Verificação e o repositório estará usando o aplicativo.
    • Se o link "Detalhes" redirecionar para o pipeline do Azure DevOps, o status terá um "estilo antigo" e o repositório não está usando o aplicativo.

  • No Azure Pipelines: você também pode determinar o tipo de conexão inspecionando o pipeline na interface do usuário do Azure Pipelines. Abra o editor do pipeline. Selecione Gatilhos para abrir o editor clássico do pipeline. Em seguida, selecione a guia YAML e, em seguida, a etapa Obter fontes. Você observará uma faixa Autorizada usando conexão: indicando a conexão de serviço que foi usada para integrar o pipeline ao GitHub. O nome da conexão de serviço é um hiperlink. Selecione-o para navegar até as propriedades de conexão de serviço. As propriedades da conexão de serviço indicarão o tipo de conexão que está sendo usada:

    • O aplicativo Azure Pipelines indica a conexão do aplicativo GitHub
    • oauth indica a conexão OAuth
    • personalaccesstoken indica autenticação com PAT

Como mudo meu pipeline para usar o aplicativo GitHub em vez do OAuth?

O uso de um aplicativo GitHub em vez da conexão OAuth ou PAT é a integração recomendada entre o GitHub e o Azure Pipelines. Para alternar para o aplicativo GitHub, siga estas etapas:

  1. Acesse aqui e instale o aplicativo na organização do GitHub do seu repositório.
  2. Durante a instalação, você será redirecionado ao Azure DevOps para escolher uma organização e um projeto do Azure DevOps. Escolha a organização e o projeto que contêm o pipeline de build clássico para o qual você deseja usar o aplicativo. Essa escolha associa a instalação do Aplicativo GitHub à sua organização do Azure DevOps. Se você escolher incorretamente, acesse esta página para desinstalar o aplicativo GitHub em sua organização do GitHub e recomeçar.
  3. Na próxima página exibida, você não precisa continuar criando um novo pipeline.
  4. Edite seu pipeline visitando a página Pipelines (por exemplo, https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build), selecionando seu pipeline e clicando em Editar.
  5. Se esse for um pipeline YAML, selecione o menu Gatilhos para abrir o editor clássico.
  6. Selecione a etapa "Obter fontes" no pipeline.
  7. Na barra verde com o texto "Autorizada usando conexão", selecione "Alterar" e selecione a conexão Aplicativo GitHub com o mesmo nome que a organização do GitHub na qual você instalou o aplicativo.
  8. Na barra de ferramentas, selecione "Salvar e colocar na fila" e, em seguida, "Salvar e colocar na fila". Selecione o link para a execução de pipeline que foi enfileirada para garantir que tenha êxito.
  9. Crie (ou feche e reabra) uma solicitação de pull no repositório GitHub para verificar se um build foi colocado na fila com êxito na seção "Verificações".

Por que um repositório GitHub não é exibido para seleção no Azure Pipelines?

Dependendo do tipo de autenticação e da propriedade do repositório, são necessárias permissões específicas.

Quando seleciono um repositório durante a criação do pipeline, recebo um erro "O repositório {repo-name} está em uso com o Aplicativo GitHub do Azure Pipelines em outra organização do Azure DevOps".

Isso significa que seu repositório já está associado a um pipeline em uma organização diferente. Os eventos de CI e PR deste repositório não funcionarão, pois serão entregues à outra organização. Aqui estão as etapas que você deve executar para remover o mapeamento para outra organização antes de continuar criando um pipeline.

  1. Abra uma solicitação de pull no repositório GitHub e faça o comentário /azp where. Isso envia um relatório para a organização do Azure DevOps para a qual o repositório está mapeado.

  2. Para alterar o mapeamento, desinstale o aplicativo da organização do GitHub e reinstale-o. Ao reinstalá-la, selecione a organização correta quando for redirecionado para o Azure DevOps.

Gatilhos com falha

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

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

  • Você está usando a conexão do aplicativo GitHub para conectar o pipeline ao GitHub? Consulte Tipos de conexão para determinar o tipo de conexão que você tem. Se você estiver usando uma conexão de aplicativo do GitHub, siga estas etapas:

    • O mapeamento está configurado corretamente entre o GitHub e o Azure DevOps? Abra uma solicitação de pull no repositório GitHub e faça o comentário /azp where. Isso envia um relatório para a organização do Azure DevOps para a qual o repositório está mapeado.

      • Se nenhuma organização estiver configurada para criar esse repositório usando o aplicativo, acesse https://github.com/<org_name>/<repo_name>/settings/installations e conclua a configuração do aplicativo.

      • Se uma organização diferente do Azure DevOps for relatada, alguém já estabeleceu um pipeline para esse repositório em uma organização diferente. No momento, temos a limitação de que só podemos mapear um repositório GitHub para uma única organização de DevOps. Somente os pipelines na primeira organização do Azure DevOps podem ser disparados automaticamente. Para alterar o mapeamento, desinstale o aplicativo da organização do GitHub e reinstale-o. Ao reinstalá-la, selecione a organização correta quando for redirecionado para o Azure DevOps.

  • Você está usando o OAuth ou o PAT para conectar o pipeline ao GitHub? Consulte Tipos de conexão para determinar o tipo de conexão que você tem. Se você estiver usando uma conexão do GitHub, siga estas etapas:

    1. As conexões OAuth e PAT dependem de webhooks para comunicar atualizações ao Azure Pipelines. No GitHub, navegue até as configurações do repositório e, em seguida, para Webhooks. Verifique se os webhooks existem. Normalmente, você deve ver três webhooks: push, pull_request e issue_comment. Caso contrário, você deverá recriar a conexão de serviço e atualizar o pipeline para usar a nova conexão de serviço.

    2. Selecione cada um dos webhooks no GitHub e verifique se o conteúdo que corresponde à confirmação do usuário existe e foi enviado com êxito ao Azure DevOps. Você poderá encontrar um erro aqui se o evento não puder ser comunicado ao Azure DevOps.

  • O tráfego do Azure DevOps pode ser limitado pelo GitHub. Quando o Azure Pipelines recebe uma notificação do GitHub, ele tenta entrar em contato com o GitHub e buscar mais informações sobre o repositório e o arquivo YAML. Se você tiver um repositório com um grande número de atualizações e solicitações de pull, essa chamada poderá falhar devido a essa limitação. Nesse caso, veja se você pode reduzir a frequência de builds usando o envio em lote ou filtros de caminho/branch mais estritos.

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

  • Você atualizou o arquivo YAML no branch correto? Se você enviar por push uma atualização para um branch, o arquivo YAML nesse mesmo branch controlará o comportamento de CI. Se você enviar por push uma atualização para um branch de origem, o arquivo YAML resultante da mesclagem do branch de origem com o branch de destino controlará o comportamento de PR. Verifique se o arquivo YAML no branch correto tem a configuração necessária de CI ou PR.

  • Você configurou o gatilho corretamente? Ao definir um gatilho YAML, você pode especificar cláusulas include e exclude para branches, tags e caminhos. Verifique se a cláusula include corresponde aos detalhes do commit e se a cláusula exclude não os exclui. Verifique a sintaxe dos gatilhos e verifique se ela é precisa.

  • Você usou variáveis para definir o gatilho ou os caminhos? Observe que não há suporte para isso.

  • Você usou modelos para seu arquivo YAML? Nesse caso, verifique se os gatilhos estão definidos no arquivo YAML principal. Não há suporte para gatilhos definidos dentro de arquivos de modelo.

  • Você excluiu os branches ou caminhos para os quais você efetuou push das alterações? Teste enviando uma alteração por push para um caminho incluído em um branch incluído. Observe que os caminhos nos gatilhos diferenciam maiúsculas de minúsculas. Certifique-se de usar a mesma formatação de maiúsculas e minúsculas das pastas reais ao especificar os caminhos nos gatilhos.

  • Você acabou de efetuar push de um novo branch? Nesse caso, o novo branch pode não iniciar uma nova execução. Confira a seção "Comportamento dos gatilhos quando novos branches são criados".

Meus gatilhos de CI ou PR vinham funcionando bem. No entanto, eles pararam de funcionar agora.

Primeiro, siga as etapas de solução de problemas na pergunta anterior e, em seguida, siga estas etapas adicionais:

  • Você tem conflitos de mesclagem em sua PR? Para um PR 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 de push ou PR? Geralmente, você pode verificar um atraso para ver se o problema é específico para um único pipeline ou é comum a todos os pipelines ou repositórios no seu projeto. Caso uma atualização de push ou PR para qualquer um desses repositórios apresente esse sintoma, podemos estar enfrentando atrasos no processamento dos eventos de atualização. Aqui estão algumas razões pelas quais um atraso pode estar acontecendo:

    • Estamos enfrentando uma interrupção doe serviço na nossa página de status. Se a página de status mostra um problema, isso significa necessariamente que nossa equipe já começou a trabalhar nele. Verifique a página com frequência para obter atualizações sobre o problema.
    • Seu repositório contém muitos pipelines YAML. Para obter o melhor desempenho, recomendamos um máximo de 50 pipelines em um único repositório. Para um desempenho aceitável, recomendamos um máximo de 100 pipelines em um único repositório. Quanto mais pipelines existirem, mais lento será o processamento de um push para esse repositório. Sempre que houver um push para um repositório, o Azure Pipelines precisa carregar todos os pipelines YAML nesse repositório para descobrir se algum deles precisa ser executado, e cada novo pipeline incorre em uma penalidade de desempenho.

Não quero que os usuários substituam a lista de branches para gatilhos quando atualizarem o arquivo YAML. Como posso fazer isso?

Os usuários com permissões para contribuir com código podem atualizar o arquivo YAML e incluir/excluir branches adicionais. Como resultado, os usuários podem incluir um recurso ou branch de usuário próprio no arquivo YAML deles e efetuar push dessa atualização para um recurso ou branch de usuário. Isso pode fazer com que o pipeline seja disparado para todas as atualizações desse branch. Se você quiser evitar esse comportamento, poderá:

  1. Editar o pipeline na interface do usuário do Azure Pipelines.
  2. Navegar até o menu Gatilhos.
  3. Selecionar Substituir o gatilho de integração contínua YAML aqui.
  4. Especifique os branches a serem incluídos ou excluídos para o gatilho.

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

Check-out com falha

Vejo o seguinte erro no arquivo de log durante a etapa de check-out. Como corrigi-la?

remote: Repository not found.
fatal: repository <repo> not found

Isso pode ser causado por uma interrupção do GitHub. Tente acessar o repositório no GitHub e verifique se é possível.

Versão errada

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

  • Para gatilhos de CI, o arquivo YAML que está no branch que você está enviando por push é avaliado para ver se um build de CI deve ser executado.
  • Para gatilhos de PR, o arquivo YAML resultante da mesclagem dos branches de origem e destino da PR é avaliado para ver se um build de PR deve ser executado.

Atualizações de status ausentes

Minha PR no GitHub está bloqueada, pois o Azure Pipelines não atualizou o status.

Isso pode ser um erro transitório que resultou na não comunicação do Azure DevOps com o GitHub. Tente fazer check-in novamente no GitHub se você usar o aplicativo GitHub. Ou faça uma atualização trivial para a PR para ver se o problema pode ser resolvido.