Partilhar via

Crie repositórios do GitHub

  • Artigo

Serviços de DevOps do Azure

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

Se você é novo na 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 utilizadores

O GitHub e o Azure Pipelines são dois serviços independentes que se integram bem juntos. 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ções e contas de usuário que contêm repositórios . Consulte documentação do GitHub.

da estrutura organizacional do GitHub

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

da estrutura organizacional do Azure DevOps

O Azure DevOps pode refletir sua estrutura do GitHub com:

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

estrutura do GitHub mapeada para o 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á um URL como https://dev.azure.com/your-organization.
  2. Na organização 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 Projeto DevOps, crie pipelines com o nome da organização e do repositório do GitHub que eles criam, como your-organization.your-repository. Em seguida, fica claro para quais repositórios eles servem.

Seguindo esse padrão, seus repositórios do GitHub e Projetos de DevOps do Azure 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

Utilizadores

Seus usuários do GitHub não obtêm acesso automaticamente aos Pipelines do Azure. 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 de uma falha de compilação ou de validação de RP 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 em DevOps usando sua identidade de DevOps.

Funções da organização do GitHub

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

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

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

Função de organização do GitHub Equivalente da organização DevOps
Proprietário Membro do Project Collection Administrators
Gestor de faturação Membro do Project Collection Administrators
Membro Membro do Project Collection Valid Users. Por padrão, o grupo Membro 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 DevOps são encontradas em https://dev.azure.com/your-organization/_settings/security (substitua your-organization).

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

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

Permissões do repositório GitHub

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

As permissões do projeto DevOps são 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 Projetos de DevOps do Azure são as seguintes.

Permissão do repositório GitHub Equivalente ao projeto DevOps
Administrador Membro do Project Administrators
Escrever Membro do Contributors
Ler Membro do Readers

Se o repositório do GitHub conceder permissão às equipes, você poderá criar equipes correspondentes na seção Teams das configurações do projeto do Azure DevOps. 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. Visite a página Pipelines do projeto (por exemplo, https://dev.azure.com/your-organization/your-project/_build).
  2. Selecione o pipeline para o qual definir permissões específicas.
  3. No menu de contexto '...', selecione Security.
  4. Selecione Adicionar... 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 novo 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 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 de checkout multi-repo .

Os Pipelines do Azure devem ter acesso aos seus repositórios para acionar suas compilações e buscar seu código durante as compilações.

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

Tipo de autenticação Os pipelines são executados usando Funciona com de verificações do GitHub
1. do aplicativo GitHub A identidade do Azure Pipelines Sim
2. OAuth Sua identidade pessoal no GitHub Não
3. Token de acesso pessoal (PAT) Sua identidade pessoal no GitHub Não

Autenticação do 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. As compilações e as atualizações de status do GitHub serão executadas usando a identidade do Azure Pipelines. O aplicativo funciona com de Verificações do GitHub para exibir resultados de cobertura de compilação, teste e código no GitHub.

Para usar o aplicativo GitHub, instale-o em sua organização ou conta de usuário do GitHub para alguns ou todos os repositórios. O aplicativo GitHub pode ser instalado e desinstalado a partir da página inicial do aplicativo .

Após a instalação, o Aplicativo GitHub se tornará o método padrão de autenticação do Azure Pipelines para o 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 e-mails em massa pelo Azure Pipelines ou a configuração automática de pipelines em seu nome. No entanto, se o aplicativo estiver instalado para todos os repositórios, o token usado pelo aplicativo terá acesso a todos os repositórios, incluindo os privados. Por razões de segurança, recomenda-se separar os repositórios públicos e privados no nível da organização. Isso significa ter uma organização dedicada apenas para projetos públicos, sem repositórios privados. Se, por algum motivo, houver a necessidade de ter repositórios públicos e privados na mesma organização, em vez de usar o acesso para todos os repositórios, selecione explicitamente os repositórios aos quais o aplicativo deve ter acesso. Isso requer mais trabalho para os administradores, mas garante um melhor gerenciamento de segurança.

Permissões necessárias no GitHub

A instalação do aplicativo GitHub do Azure Pipelines requer que você seja proprietário de uma organização do GitHub ou administrador do repositório. Além disso, para criar um pipeline para um repositório GitHub com integração contínua e gatilhos de solicitação pull, 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 durante a criação de um pipeline. Dependendo do tipo de autenticação e da propriedade do repositório, certifique-se de que o acesso apropriado esteja 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 que lhe é enviado por e-mail. Depois de fazer isso, você pode criar um pipeline para esse repositório.

  • Se o repositório estiver em uma organização do GitHub de sua propriedade, 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 do GitHub ou administrador do repositório 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 que lhe é enviado por e-mail.

Permissões do aplicativo 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 confirmando um arquivo YAML em uma ramificação selecionada do repositório GitHub.
Acesso de leitura aos metadados O Azure Pipelines recuperará metadados do GitHub para exibir o repositório, ramificações e problemas associados a uma compilação no resumo da compilação.
Acesso de leitura e gravação a cheques O Azure Pipelines lerá e gravará seus próprios resultados de compilação, teste e cobertura de código a serem exibidos no GitHub.
Acesso de leitura e gravação para solicitações pull Somente após sua ação deliberada, o Azure Pipelines simplificará a criação de um pipeline criando uma solicitação pull para um arquivo YAML que foi confirmado em uma ramificação selecionada do repositório GitHub. Pipelines recupera metadados de solicitação para exibir em resumos de compilação associados a solicitações pull.

Solução de problemas de 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 é instalado, pipelines podem 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 acionados automaticamente por confirmações ou solicitações pull do GitHub. Compilações manuais ou agendadas ainda são possíveis em organizações secundárias do Azure DevOps.

Autenticação OAuth

OAuth é o tipo de autenticação mais simples de começar para repositórios em sua conta pessoal do GitHub. As atualizações de status do GitHub serão realizadas 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 Escolha um de conexão diferente abaixo da lista de repositórios ao criar um pipeline. Em seguida, selecione Autorizar para entrar no GitHub e autorizar com OAuth. Uma conexão OAuth será salva em seu projeto de DevOps do Azure 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 integração contínua e gatilhos de solicitação pull, 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 durante a criação de um pipeline. Dependendo do tipo de autenticação e da propriedade do repositório, certifique-se de que o acesso apropriado esteja configurado.

  • Se o repositório estiver em sua conta pessoal do GitHub, pelo menos uma vez, autentique-se no GitHub com OAuth usando suas credenciais pessoais de conta do GitHub. Isso pode ser feito nas configurações do projeto do Azure DevOps em Pipelines > conexões de serviço > Nova conexão de 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 OAuth usando suas credenciais pessoais de conta do GitHub. Isso pode ser feito nas configurações do projeto do Azure DevOps em Pipelines > conexões de serviço > Nova conexão de serviço > GitHub > Autorizar. A outra pessoa deve conceder acesso ao Azure Pipelines 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 que lhe é enviado por e-mail.

  • Se o repositório estiver em uma organização do GitHub de sua propriedade, pelo menos uma vez, autentique-se no GitHub com OAuth usando suas credenciais pessoais de conta do GitHub. Isso pode ser feito nas configurações do projeto do Azure DevOps em Pipelines > conexões de serviço > Nova conexão de serviço > GitHub > Autorizar. Conceda acesso ao Azure Pipelines à sua organização em "Acesso à 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, o proprietário da organização do GitHub deverá se autenticar no GitHub com OAuth usando suas credenciais pessoais de conta do GitHub. Isso pode ser feito nas configurações do projeto do Azure DevOps em Pipelines > conexões de serviço > Nova conexão de serviço > GitHub > Autorizar. O proprietário da organização deve conceder acesso ao Azure Pipelines à organização em "Acesso à 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 que lhe é enviado por e-mail.

Revogar acesso OAuth

Depois de autorizar o Azure Pipelines a usar o OAuth, para posteriormente revogá-lo e impedir o uso adicional, visite de 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 de token de acesso pessoal (PAT)

PATs são efetivamente iguais ao OAuth, mas permitem que você controle quais permissões são concedidas ao Azure Pipelines. Compilações e atualizações de status do GitHub serão realizadas em nome de sua identidade pessoal do GitHub. Para que as compilações continuem funcionando, o acesso ao repositório deve permanecer ativo.

Para criar um PAT, visite tokens de acesso pessoal nas configurações do GitHub. As permissões necessárias são repo, admin:repo_hook, read:usere user:email. Estas 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 um novo de conexão de serviço do GitHub nas configurações do projeto do Azure DevOps. Para recuperação futura, nomeie a conexão de serviço após seu nome de usuário do GitHub. Ele estará disponível em seu projeto de DevOps do Azure para uso posterior ao criar pipelines.

Permissões necessárias no GitHub

Para criar um pipeline para um repositório GitHub com integração contínua e gatilhos de solicitação pull, 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 durante a criação de um pipeline. Dependendo do tipo de autenticação e da propriedade do repositório, certifique-se de que o acesso a seguir esteja configurado.

  • Se o repositório estiver na sua conta pessoal do GitHub, a PAT deve ter os escopos de acesso necessários em tokens de acesso pessoal: repo, admin:repo_hook, read:usere user:email.

  • Se o repositório estiver na conta pessoal do GitHub de outra pessoa, a PAT deverá ter os escopos de acesso necessários em tokens de acesso pessoal: repo, admin:repo_hook, read:usere 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 que lhe é enviado por e-mail.

  • Se o repositório estiver em uma organização do GitHub de sua propriedade, a PAT deverá ter os escopos de acesso necessários em tokens de acesso pessoal: repo, admin:repo_hook, read:usere 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, a PAT deverá ter os escopos de acesso necessários em tokens de acesso pessoal: repo, admin:repo_hook, read:usere 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 que lhe é enviado por e-mail.

Revogar o acesso à PAT

Depois de autorizar o Azure Pipelines a usar um PAT, para excluí-lo posteriormente e impedir o uso posterior, visite de tokens de acesso pessoal 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.

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.

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 de gatilho de CI YAML implícita Desabilitar, introduzida em de sprint 227 do Azure DevOps, esteja habilitada. A configuração Desabilitar de 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 de gatilho YAML implícito está habilitada, os gatilhos de CI para pipelines YAML não são habilitados se o pipeline YAML não tiver uma seção trigger. Por padrão, Desativar de gatilho YAML CI implícito não está habilitado.

Sucursais

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, main) ou um curinga (por exemplo, releases/*). Consulte Curingas para obter informações sobre a sintaxe curinga.

Observação

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

Observação

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 main ou para 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 exclude sem uma cláusula include, isso equivale a especificar * na cláusula include.

Além de especificar nomes de ramificações nas listas de 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 Desativar 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

Observação

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

Para esclarecer este exemplo, digamos que um push A para main fez com que o pipeline acima fosse executado. Enquanto esse pipeline está em execução, envios adicionais B e C ocorrer 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 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 ser iniciada. 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.

Percursos

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 com apenas 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 filtrar 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 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).

Etiquetas

Além de especificar tags nas listas de branches, conforme abordado na seção anterior, você pode especificar diretamente as tags a serem incluídas ou excluídas:

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

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

Importante

Se você especificar tags em combinação com filtros de ramificação, o gatilho será acionado se o filtro de ramificação estiver satisfeito ou se o filtro de tags estiver satisfeito. Por exemplo, se uma tag push satisfizer o filtro de ramificação, o pipeline será acionado mesmo se a tag for excluída pelo filtro de tag, porque o push satisfez o filtro de ramificação.

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.

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 de 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 de sistema Build.Reason. 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 por push uma atualização para a pasta docs e outro para disparar quando você enviar por push uma atualização para o código do 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.

Curingas

Ao especificar uma ramificação, marca ou caminho, você pode usar um nome exato ou um curinga. Os padrões curinga permitem que * correspondam a zero ou mais caracteres e ? correspondam 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ê pode não incluir* no meio de um filtro de caminho e não pode usá?.
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.

Sucursais

Você pode especificar as ramificações de destino ao validar suas solicitações pull. Por exemplo, para validar solicitações pull direcionadas a main 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, main) ou um curinga (por exemplo, releases/*).

Observação

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

Observação

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.

O GitHub cria um novo ref quando uma solicitação pull é criada. A ref aponta para um merge commit, que é o código mesclado entre as ramificações de origem e destino da solicitação pull. O pipeline de validação de RP cria a confirmação para a qual esse ref aponta. Isso significa que o arquivo YAML usado para executar o pipeline também é uma mesclagem entre a ramificação de origem e de destino. Como resultado, as alterações feitas no arquivo YAML na ramificação de origem da solicitação pull podem substituir o comportamento definido pelo arquivo YAML na ramificação de destino.

Se nenhum gatilho pr aparecer em 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 aciona 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 de pr com um subconjunto de ramificações, um pipeline é acionado somente quando as atualizações são enviadas por push para essas ramificações.

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

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

Percursos

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

Dicas:

  • O Azure Pipelines publica um status neutro de volta ao GitHub quando decide não executar uma compilação 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, consulte Postar status neutro no GitHub quando uma compilação é ignorada.
  • Curingas agora são suportados 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).
  • O Azure Pipelines publica um status neutro de volta ao GitHub quando decide não executar uma compilação de validação devido a uma regra de exclusão de caminho.

Várias atualizações de RP

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

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

Validação de rascunho de RP

Por padrão, a solicitação pull aciona as solicitações pull de rascunho e as solicitações pull que estão prontas para revisão. Para desativar os gatilhos de solicitação pull para solicitações 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

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 de gatilho PR no esquema YAML .

Observação

Se o gatilho do não estiver disparando, siga as etapas de solução de problemas node perguntas frequentes do .

Se você tiver uma RP aberta e enviar alterações para sua ramificação de origem, vários pipelines poderão ser executados:

  • Os pipelines que têm um gatilho de RP na ramificação de destino do PR serão executados no de confirmação de mesclagem (o código mesclado entre as ramificações de origem e de destino da solicitação pull), independentemente de existirem confirmações enviadas cujas mensagens ou descrições contenham [skip ci] (ou qualquer uma de suas variantes).
  • Os pipelines acionados por alterações na ramificação de origem do PR, se não houver nenhum push commits cujas mensagens ou descrições contenham [skip ci] (ou qualquer uma de suas variantes). Se pelo menos uma confirmação enviada contiver [skip ci], os pipelines não serão executados.

Finalmente, depois de mesclar a RP, o Azure Pipelines executará os pipelines de CI acionados por pushes para a ramificação de destino, se a mensagem ou descrição da confirmação de mesclagem não contiver [skip ci] (ou qualquer uma de suas variantes).

Ramos protegidos

Você pode executar uma compilação de validação com cada solicitação commit ou pull direcionada a uma ramificação e até mesmo impedir que solicitações pull sejam mescladas até que uma compilação de validação seja bem-sucedida.

Para configurar compilações de validação obrigatórias para um repositório GitHub, você deve ser seu proprietário, um colaborador com a função Admin ou um membro da organização do GitHub com a função Write.

  1. Primeiro, crie um pipeline para o repositório e construa-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 como configurar ramificações protegidas nas configurações do repositório.

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

    de verificação de status do pipeline do GitHub

Importante

Se o seu pipeline não aparecer nesta lista, certifique-se do seguinte:

  • Você está usando de autenticação de aplicativo GitHub
  • Seu pipeline funcionou pelo menos uma vez na última semana

Contribuições de fontes externas

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

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

Restrições de acesso

Esteja ciente das seguintes restrições de acesso quando estiver executando pipelines em projetos públicos do Azure DevOps:

  • Segredos: Por padrão, os segredos associados ao seu pipeline não são disponibilizados para validar solicitações de pull de forks. Consulte Validar contribuições de forks.
  • 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 compilação ou resultados de teste somente dentro do projeto e não em outros projetos da organização do Azure DevOps.
  • pacotes de Artefatos do Azure: Se seus pipelines precisarem de acesso a pacotes do Azure Artifacts, você deverá conceder explicitamente permissão à conta do Serviço de Criação do Project para acessar os feeds de pacote.

Contribuições de garfos

Importante

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

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

  1. Vá para seu projeto do Azure DevOps. Selecione Pipelines, localize seu pipeline e selecione Editar.
  2. Selecione a guia Triggers. Depois de habilitar o gatilho de solicitação Pull, habilite ou desabilite a caixa de seleção Build pull requests from forks of this repository.

Por padrão, com os pipelines do GitHub, os segredos associados ao seu pipeline de compilação não são disponibilizados para obter compilações de solicitação de forks. Esses segredos são habilitados por padrão com os pipelines do GitHub Enterprise Server. Os segredos incluem:

  • Um token de segurança com acesso ao seu repositório GitHub.
  • Esses itens, se o pipeline usá-los:

Para ignorar essa precaução nos pipelines do GitHub, habilite a caixa de seleção Disponibilizar segredos para compilações de forks. Esteja ciente 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 compilações de bifurcação. Ele tem acesso mais limitado a recursos abertos do que um token de acesso normal. Para conceder às compilações fork as mesmas permissões que as compilações regulares, habilite a configuração Make fork builds tenham as mesmas permissões que as compilações regulares.

Para obter mais informações, consulte Repository protection - Forks.

Você pode definir centralmente como os pipelines criam PRs a partir de repositórios bifurcados do GitHub usando o controle solicitações de pull de construção de repositórios do GitHub bifurcados. Está disponível a nível de organização e projeto. Pode optar por:

  • Desativar a criação de solicitações pull de repositórios bifurcados
  • Crie solicitações pull com segurança a partir de repositórios bifurcados
  • Personalizar regras para criar solicitações pull de repositórios bifurcados

Captura de tela das configurações de controle centralizado de como os pipelines criam PRs a partir de repositórios bifurcados do GitHub.

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

Quando você escolhe a opção Construir com segurança a partir de repositórios bifurcados, todos os pipelines, organização ou todo o projeto, não podem disponibilizar segredos para compilações de RPs a partir 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 RP. Os projetos ainda podem decidir não permitir gasodutos para construir tais RPs.

Ao escolher a opção Personalizar, você pode definir como restringir as configurações do pipeline. Por exemplo, você pode garantir que todos os pipelines exijam um comentário para criar um PR a partir de um repositório GitHub bifurcado, quando o PR pertence a membros que não são da equipe e não contribuidores. Mas, você pode optar por permitir que eles disponibilizem segredos para tais construções. Os projetos podem decidir não permitir que os pipelines criem tais RPs, ou criá-los com segurança, ou ter configurações ainda mais restritivas do que as especificadas no nível da organização.

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

Considerações importantes de segurança

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

  • Vaze segredos do seu pipeline. Para reduzir esse risco, não habilite a caixa de seleção Disponibilizar segredos para compilações de bifurcações se o repositório for público ou se os usuários não confiáveis puderem enviar solicitações pull que acionem compilações automaticamente. Esta opção está desativada por padrão.

  • Comprometa a máquina que executa o agente para roubar código ou segredos de outros pipelines. Para atenuar esta situação:

    • Use um de pool de agentes hospedados pela Microsoft para criar solicitações pull a partir de bifurcações. As máquinas de agente hospedadas pela Microsoft são excluídas imediatamente após concluírem uma compilação, portanto, não há impacto duradouro se forem comprometidas.

    • 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 nos criadores de pull request.

Gatilhos de comentário

Os colaboradores do repositório podem comentar uma solicitação pull para executar manualmente um pipeline. Aqui estão algumas razões comuns pelas quais você pode querer fazer isso:

  • Talvez você não queira criar automaticamente solicitações pull de usuários desconhecidos até que suas alterações possam ser revisadas. Você deseja que um dos membros da sua equipe primeiro revise seu código e, em seguida, execute o pipeline. Isso é comumente usado como uma medida de segurança ao criar código contribuído a partir de repositórios bifurcados.
  • Você pode querer executar um conjunto de testes opcional ou mais uma compilação de validação.

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

  1. Habilite gatilhos de solicitação pull para seu pipeline e certifique-se de que você não excluiu a ramificação de destino.
  2. No portal da Web do Azure Pipelines, edite seu pipeline e escolha Mais ações, Triggers. Em seguida, em de validação de solicitação pull , habilite Exigir comentário de um membro da equipe antes de criar uma solicitação pull.
    • Escolha Em todas as solicitações pull exigir o comentário de um membro da equipe antes de criar uma solicitação pull. Com esse fluxo de trabalho, um membro da equipe analisa a solicitação pull e dispara a compilação com um comentário assim que a solicitação pull for considerada segura.
    • Escolha Somente em solicitações pull de membros que não são da equipe para exigir o comentário de um membro da equipe somente quando um RP for feito por um membro que não seja da equipe. Neste fluxo de trabalho, um membro da equipe não precisa da revisão de um membro secundário da equipe para acionar uma compilação.

Com essas duas alterações, a compilação de validação de solicitação pull não será acionada automaticamente, a menos que Somente em solicitações pull de membros que não sejam da equipe seja selecionada e a RP seja feita por um membro da equipe. Somente os proprietários e colaboradores do repositório com permissão 'Gravar' podem acionar a compilação comentando a solicitação pull com /AzurePipelines run ou /AzurePipelines run <pipeline-name>.

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

Comando Resultado
/AzurePipelines help Exiba ajuda para todos os comandos suportados.
/AzurePipelines help <command-name> Exiba a ajuda para o comando especificado.
/AzurePipelines run Execute todos os pipelines associados a este repositório e cujos gatilhos não excluam essa solicitação pull.
/AzurePipelines run <pipeline-name> Execute o pipeline especificado, a menos que seus gatilhos excluam essa solicitação pull.

Observação

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

Importante

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

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

Se você tiver as permissões de repositório necessárias, mas os pipelines não estiverem sendo acionados por seus comentários, certifique-se de que sua associação seja 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 de organizações privadas, 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 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.

Captura de tela de uma execução de pipeline informativo.

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.

Finalizar encomenda

Quando um pipeline é acionado, o Azure Pipelines extrai seu código-fonte do repositório Git do Azure Repos. Você pode controlar vários aspetos de como isso acontece.

Observação

Quando você inclui uma etapa de checkout em seu 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ê pode optar por excluir o check-out interno por checkout: none e, em seguida, usar uma tarefa de script para executar seu próprio checkout.

Versão preferida do Git

O agente do Windows vem com sua própria cópia do Git. Se você preferir fornecer seu próprio 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 um único repositório, por padrão, o check-out do código-fonte será feito 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, será feito check-out do código-fonte no C:\agent\_work\1\mycustompath.

Se você estiver usando várias etapas de checkout e 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ê fizer check-out de dois repositórios chamados tools e code, será feito check-out do código-fonte em C:\agent\_work\1\s\tools e C:\agent\_work\1\s\code.

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

Você pode definir a configuração de na etapa Checkout do do seu 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ê pode definir a configuração na etapa Checkout do 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 construção verificará seus submódulos do Git desde que sejam:

  • Não autenticado: Um repositório público não autenticado sem credenciais necessárias para clonar ou buscar.

  • Autenticado:

    • Contido no mesmo projeto que o repositório Git do Azure Repos especificado acima. As mesmas credenciais que são usadas pelo agente para obter os códigos-fonte do repositório principal também são usadas para obter os códigos-fonte para submódulos.

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

      • Este seria verificado: 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 que são usadas pelo agente para obter os códigos-fonte do repositório principal também são usadas para obter os códigos-fonte para submódulos. Isso requer que o token de acesso ao trabalho tenha acesso ao repositório no segundo projeto. Se você restringiu 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 concedendo explicitamente acesso à conta de serviço de compilação 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 suas implicações de segurança, consulte acessar repositórios, artefatos e outros recursos.

      • Este não seria verificado: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

Alternativa ao uso da opção de submódulos Checkout

Em alguns casos, não é possível usar a opção submódulos Checkout. Você pode ter um cenário em que um conjunto diferente de credenciais é necessário para acessar os submódulos. Isso pode acontecer, por exemplo, se o repositório principal e os repositórios do submódulo não estiverem 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 submódulos Checkout, poderá usar uma etapa de script personalizada para buscar submódulos. Primeiro, obtenha um token de acesso pessoal (PAT) e prefixe-o com pat:. Em seguida, codificar base64 essa cadeia de caracteres prefixada para criar um token de autenticação básico. Finalmente, adicione este script ao seu pipeline:

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

Certifique-se de substituir "<BASE64_ENCODED_STRING>" pela sua cadeia de caracteres "pat:token" codificada em Base64.

Use uma variável secreta em seu projeto ou pipeline de construção para armazenar o token de autenticação básico que você gerou. 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 Git no agente?R: Armazenar as credenciais do submódulo em um gerenciador de credenciais Git instalado em seu agente de compilação privado geralmente não é eficaz, pois o gerenciador de credenciais pode solicitar que você insira novamente as credenciais sempre que o submódulo for atualizado. Isso não é desejável durante compilações automatizadas quando a interação do usuário não é possível.

Sincronizar tags

Importante

O recurso de marcas de sincronização é suportado no Azure Repos Git com o Azure DevOps Server 2022.1 e superior.

A etapa de checkout usa a opção --tags ao buscar o conteúdo de um repositório Git. Isso faz com que o servidor busque 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 checkout sincroniza as tags mesmo quando você ativa a opção de busca superficial, possivelmente derrotando seu propósito. Para reduzir a quantidade de dados buscados ou extraídos de um repositório Git, a Microsoft adicionou uma nova opção de checkout para controlar o comportamento de sincronização de tags. Esta opção está disponível em pipelines clássicos e YAML.

A sincronização de tags ao fazer check-out de um repositório pode ser configurada no YAML definindo a propriedade e na interface do usuário configurando a configuração tags Sync.

Você pode definir a configuração de na etapa Checkout do do seu pipeline.

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

steps:
- checkout: self
  fetchTags: true

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

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

    Captura de tela do menu de mais gatilhos.

  2. Escolha YAML Obter fontes.

    Captura de tela de Obter fontes.

  3. Configure a configuração tags do Sync.

    Captura de ecrã da definição Sincronizar etiquetas.

Observação

Se você definir explicitamente fetchTags na etapa checkout, essa configuração terá prioridade sobre a configuração definida na interface do usuário de configurações de 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 tags permanece o mesmo que o comportamento existente antes da adição das opções de de tags Sync, que é .
  • Para novos pipelines criados após a versão 209 do sprint do Azure DevOps, o padrão para sincronizar marcas é false.

Observação

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

Busca rasa

Você pode querer limitar o tempo de volta no histórico para baixar. Efetivamente, isso resulta em git fetch --depth=n. Se o repositório for grande, essa opção pode tornar o pipeline de compilação mais eficiente. Seu repositório pode ser grande se estiver em uso por um longo tempo e tiver um histórico considerável. Também pode ser grande se você adicionou e depois excluiu arquivos grandes.

Importante

Os novos pipelines criados após a atualização do Azure DevOps 209 de de setembro de 2022 ter de busca superficial habilitados por padrão e configurados com uma profundidade de 1. Anteriormente, o padrão era não buscar superficialmente. Para verificar seu pipeline, exiba a configuração de busca superficial na interface do usuário de configurações do pipeline, conforme descrito na seção a seguir.

Você pode definir a configuração de na etapa Checkout do do seu 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 de busca definindo a opção Profundidade superficial na interface do usuário de configurações do pipeline.

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

    Captura de tela do menu de mais gatilhos.

  2. Escolha YAML Obter fontes.

    Captura de tela de Obter fontes.

  3. Configure a configuração busca superficial. Desmarque de busca superficial para desativar a busca superficial ou marque a caixa e insira um de profundidade para habilitar a busca rasa.

    Captura de tela das opções.

Observação

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

Nesses casos, essa opção pode ajudá-lo a conservar recursos de rede e armazenamento. Também pode poupar tempo. A razão pela qual nem sempre economiza tempo é porque, em algumas situações, o servidor pode precisar gastar tempo calculando as confirmações a serem baixadas para a profundidade que você especificar.

Observação

Quando o pipeline é iniciado, a ramificação a ser criada é resolvida para uma ID de confirmação. Em seguida, o agente busca a ramificação e verifica a confirmação desejada. Há uma pequena janela entre quando uma ramificação é resolvida para uma ID de confirmação e quando o agente executa o check-out. Se a ramificação for atualizada rapidamente e você definir um valor muito pequeno para busca superficial, a confirmação pode não existir quando o agente tentar fazer check-out. Se isso acontecer, aumente a configuração de profundidade de busca rasa.

Não sincronizar fontes

Você pode querer pular a busca de novas confirmações. Esta opção pode ser útil nos casos em que pretende:

  • Git init, config e fetch usando suas próprias opções personalizadas.

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

Você pode configurar a configuração Não sincronizar fontes na etapa Checkout do do seu pipeline, definindo .

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 do Git que limpam o repositório.

Construção limpa

Você pode executar diferentes formas de limpeza do diretório de trabalho do seu agente auto-hospedado antes que uma compilação seja executada.

Em geral, para um desempenho mais rápido de seus agentes auto-hospedados, não limpe o repositório. Neste caso, para obter o melhor desempenho, certifique-se de que também está a criar de forma incremental, desativando qualquer opção Limpar da tarefa ou ferramenta que está a utilizar para criar.

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

Observação

A limpeza não é eficaz se você estiver usando um agente hospedado pela Microsoft porque você receberá um novo agente toda vez.

Você pode definir a configuração de na etapa Checkout do do seu 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 está definido para true o pipeline de compilação executa um desfazer de quaisquer alterações no $(Build.SourcesDirectory). Mais especificamente, os seguintes comandos do Git são executados antes de buscar a fonte.

git clean -ffdx
git reset --hard HEAD

Para obter mais opções, você pode definir a configuração de de umde 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 dá as seguintes opções de limpeza.

  • saídas: Mesma operação que a configuração de limpeza descrita na tarefa de checkout anterior, além de: Exclui e recria $(Build.BinariesDirectory). Observe que os $(Build.ArtifactStagingDirectory) e $(Common.TestResultsDirectory) são sempre excluídos e recriados antes de cada compilação, independentemente de qualquer uma dessas configurações.

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

  • todos os: Exclui e recria $(Agent.BuildDirectory). Isso resulta na inicialização de um novo repositório Git local para cada compilação.

Fontes de etiquetas

Você pode querer rotular seus arquivos de código-fonte para permitir que sua equipe identifique facilmente qual versão de cada arquivo está incluída na compilação concluída. Você também tem a opção de especificar se o código-fonte deve ser rotulado para todas as compilações ou apenas para compilações bem-sucedidas.

No momento, você não pode definir essa configuração no YAML, mas pode fazê-lo no editor clássico. Ao editar um pipeline YAML, você pode acessar o editor clássico escolhendo Triggers no menu do editor YAML.

Configurar opções do Git, YAML.

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

No editor Clássico, escolha YAML > Obter fontes.

No formato 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 compilação rotula suas fontes com uma tag Git .

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

Depois que os códigos-fonte são marcados pelo pipeline de compilação, um artefato com a refs/tags/{tag} ref do Git é adicionado automaticamente à compilação concluída. Isso dá à sua equipe rastreabilidade adicional e uma maneira mais amigável de navegar da compilação para o código que foi criado. A tag é considerada um artefato de construção, uma vez que é produzida pela compilação. Quando a compilação é excluída manualmente ou por meio de uma política de retenção, a tag também é excluída.

Variáveis pré-definidas

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

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

Atualizações de status

Há dois tipos de status que o Azure Pipelines publica de volta ao GitHub - status básico e Execução de verificação do GitHub. A funcionalidade de Verificações do GitHub só está disponível com os Aplicativos do GitHub.

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

  • Para RPs, eles são exibidos na guia Conversas de RP.
  • Para confirmações individuais, elas são exibidas ao passar o mouse sobre a marca de status após o tempo de confirmação na guia confirmações do repositório.

Conexões PAT ou OAuth GitHub

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

Os status das conexões PAT ou OAuth 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 lançar status separados para a mesma confirmação.

Verificações do GitHub

Para pipelines configurados usando o aplicativo Pipelines do Azure GitHub, 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 o teste do pipeline, a cobertura do código e os 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 de volta 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 para um PR/commit. Você pode optar por "reexecutar" a Verificação individual, executar novamente todas as Verificações com falha nesse PR/commit, ou executar novamente todas as Verificações, independentemente de terem sido bem-sucedidas inicialmente ou não.

Verificações do GitHub são executadas novamente

Clicar no link "Executar novamente" ao lado do nome Verificar Execução resultará em Pipelines do Azure repetindo a execução 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 a compilação inicial. Apenas os trabalhos que falharam na execução inicial e quaisquer trabalhos a jusante 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 "Repetir execução" na interface do usuário do Azure Pipelines. Clicar em "Executar novamente todas as verificações" resultará em uma nova execução, com um novo número de execução e pegará 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 para um repositório aumenta com o número de pipelines nesse repositório. Sempre que há 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 carregar cada pipeline incorre em uma penalidade de 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 os Pipelines do Azure podem fazer muitas solicitações em um curto período de tempo.

  • O uso de estende e incluir modelos 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, precisa buscar todos os arquivos de modelo.

  • 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 janela Selecionar uma ramificação para a ramificação Padrão para compilações manuais e agendadas configuração 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 no campo ramificação padrão para compilações manuais e agendadas.

    Se você clicar nas reticências e abrir a caixa de diálogo Selecionar uma ramificação e fechá-la sem escolher uma ramificação válida na lista suspensa, poderá ver uma Algumas configurações precisam de atenção mensagem e um Essa configuração é necessária mensagem abaixo ramificação padrão para compilações manuais e agendadas. Para contornar essa mensagem, reabra o pipeline e digite o nome diretamente na ramificação Padrão para compilações manuais e agendadas campo.

Perguntas Frequentes

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

  • Tipos de conexão: Não tenho certeza de que tipo de conexão estou usando para conectar meu pipeline ao GitHub.
  • Disparos com falha: Meu pipeline não está sendo acionado quando envio uma atualização para o repositório.
  • Falha no checkout: Meu pipeline está sendo acionado, mas falha na etapa de checkout.
  • Versão errada: Meu pipeline é executado, mas está usando uma versão inesperada do source/YAML.
  • Atualizações de status ausentes: Meus PRs do GitHub estão bloqueados porque o Azure Pipelines não relatou uma atualização de status.

Tipos de ligação

Para solucionar problemas de gatilhos, como sei 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 - do GitHub e do Azure Pipelines.

  • Do GitHub: Se um repositório estiver configurado para usar o aplicativo GitHub, os status em PRs e commits serão Check Runs. 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 Check Runs ou status simples é olhar para a guia "conversa" em um PR do GitHub.

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

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

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

Como faço para mudar meu pipeline para usar o aplicativo GitHub em vez de OAuth?

Usar um aplicativo GitHub em vez de conexão OAuth ou PAT é a integração recomendada entre o GitHub e o Azure Pipelines. Para mudar para a aplicação GitHub, siga estes passos:

  1. Navegue aqui e instale o aplicativo na organização GitHub do seu repositório.
  2. Durante a instalação, você será redirecionado para o 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 compilação clássico para o qual você deseja usar o aplicativo. Essa opção associa a instalação do Aplicativo GitHub à sua organização do Azure DevOps. Se você escolher incorretamente, você pode visitar esta página desinstalar o aplicativo GitHub da sua organização GitHub e começar de novo.
  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 este 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 "Autorizado usando conexão", selecione "Alterar" e selecione a conexão do aplicativo GitHub com o mesmo nome da organização do GitHub na qual você instalou o aplicativo.
  8. Na barra de ferramentas, selecione "Salvar e enfileirar" e, em seguida, "Salvar e enfileirar". Selecione o link para a execução do pipeline que foi enfileirado para garantir que ele seja bem-sucedido.
  9. Crie (ou feche e reabra) uma solicitação pull em seu repositório GitHub para verificar se uma compilação está enfileirada com êxito em sua seção "Verificações".

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

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

  • Se você estiver usando o aplicativo GitHub, consulte de autenticação do aplicativo GitHub.
  • Se estiver a utilizar o OAuth, consulte de autenticação OAuth .
  • Se você estiver usando PATs, consulte autenticação de token de acesso pessoal (PAT).

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 RP deste repositório não funcionarão, pois serão entregues à outra organização. Aqui estão as etapas que você deve seguir para remover o mapeamento para a outra organização antes de prosseguir para criar um pipeline.

  1. Abra uma solicitação pull no repositório do GitHub e faça o comentário /azp where. Isso relata 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á-lo, certifique-se de selecionar a organização correta quando for redirecionado para o Azure DevOps.

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 substituídos pelas configurações de pipeline na interface do usuário? Ao editar seu pipeline, escolha ... e, em seguida, Triggers.

    UI de configurações de pipeline.

    Verifique a Substituir o gatilho YAML a partir daqui configuração para os tipos de gatilho ( de integração contínua ou Pull request validation) disponíveis para o seu repositório.

    Substituir o gatilho YAML a partir daqui.

  • 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 GitHub, siga estas etapas:

    • O mapeamento está configurado corretamente entre o GitHub e o Azure DevOps? Abra uma solicitação pull no repositório do GitHub e faça o comentário /azp where. Isso relata 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, vá para 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. Atualmente, temos a limitação de que só podemos mapear um repositório do GitHub para uma única organização de DevOps. Somente os pipelines na primeira organização do Azure DevOps podem ser acionados automaticamente. Para alterar o mapeamento, desinstale o aplicativo da organização do GitHub e reinstale-o. Ao reinstalá-lo, certifique-se de selecionar a organização correta quando for redirecionado para o Azure DevOps.

  • Você está usando OAuth ou 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 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ê deve 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 a carga que corresponde à confirmação do usuário existe e foi enviada com êxito para o Azure DevOps. Você pode ver 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 pull, essa chamada pode falhar devido a essa limitação. Nesse caso, veja se é possível reduzir a frequência das compilações usando filtros de caminho em lote ou de ramo/ramificação mais rígidos.

  • 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 e, em seguida, siga estas etapas 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 um atraso verificando 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. Aqui estão algumas razões pelas quais um atraso pode estar acontecendo:

    • 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.
    • 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 houver, mais lento será o processamento de um push para esse repositório. Sempre que há 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 ramificações 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 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.

Falha no checkout

Vejo o seguinte erro no arquivo de log durante a etapa de checkout. Como faço para corrigi-lo?

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 certifique-se de que você é capaz.

Versão errada

Uma versão errada do arquivo YAML está sendo usada no pipeline. A que se deve isso?

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

Atualizações de status ausentes

Minha RP no GitHub está bloqueada porque o Azure Pipelines não atualizou o status.

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