Compilar repositórios do GitHub Enterprise Server

  • Artigo

Azure DevOps Services

Você pode integrar seu GitHub Enterprise Server local ao Azure Pipelines. O servidor local pode ser exposto à Internet ou não.

Se o GitHub Enterprise Server estiver acessível nos servidores que executam o serviço do Azure Pipelines, então:

  • você pode configurar pipelines clássicos de build e YAML
  • você pode configurar CI, PR e gatilhos de agendamento

Se o GitHub Enterprise Server não estiver acessível nos servidores que executam o serviço Azure Pipelines, então:

  • você só pode configurar pipelines de build clássicos
  • você só pode iniciar builds manuais ou agendados
  • você não pode configurar pipelines YAML
  • você não pode configurar gatilhos de CI ou PR para seus pipelines de build clássicos

Se o servidor local estiver acessível por meio de agentes hospedados pela Microsoft, você poderá usá-los para executar seus pipelines. Caso contrário, você deve configurar agentes auto-hospedados que podem acessar o servidor local e buscar o código.

Acessível do Azure Pipelines

A primeira coisa a verificar é se o GitHub Enterprise Server pode ser acessado pelo serviço Azure Pipelines.

  1. Na interface do usuário do Azure DevOps, navegue até as configurações do projeto e selecione Conexões de Serviço em Pipelines.
  2. Selecione Nova conexão de serviço e escolha GitHub Enterprise Server como o tipo de conexão.
  3. Insira as informações necessárias para criar uma conexão com seu GitHub Enterprise Server.
  4. Selecione Verificar no painel de conexão de serviço.

Se a verificação for aprovada, os servidores que executam o serviço Azure Pipelines poderão acessar seu GitHub Enterprise Server local. Você pode continuar e configurar a conexão. Em seguida, você pode usar essa conexão de serviço ao criar um build clássico ou um pipeline YAML. Você também pode configurar gatilhos CI e PR para o pipeline. A maioria dos recursos do Azure Pipelines que funcionam com o GitHub também funcionam com o GitHub Enterprise Server. Analise a documentação do GitHub para entender esses recursos. Aqui estão algumas diferenças:

  • A integração entre o GitHub e o Azure Pipelines é facilitada por meio de um aplicativo do Azure Pipelines no GitHub Marketplace. Esse aplicativo permite que você configure uma integração sem precisar contar com o token OAuth de um usuário específico. Não temos um aplicativo semelhante que funcione com o GitHub Enterprise Server. Portanto, você deve usar um PAT, nome de usuário e senha, ou OAuth para configurar a conexão entre o Azure Pipelines e o servidor GitHub Enterprise.
  • O Azure Pipelines oferece suporte a vários recursos de segurança do GitHub para validar contribuições de bifurcações externas. Por exemplo, os segredos armazenados em um pipeline não são disponibilizados para um trabalho em execução. Essas proteções não estão disponíveis ao trabalhar com o servidor GitHub Enterprise.
  • Os gatilhos de comentário não estão disponíveis com o servidor GitHub Enterprise. Você não pode usar comentários em uma solicitação pull do repositório do servidor GitHub Enterprise para acionar um pipeline.
  • As Verificações do GitHub não estão disponíveis no GitHub Enterprise Server. Todas as atualizações de status são por meio de status básicos.

Não acessível do Azure Pipelines

Quando a verificação de uma conexão do GitHub Enterprise Server, conforme explicado na seção acima, falha, o Azure Pipelines não pode se comunicar com o servidor. Isso provavelmente é causado pela forma como sua rede corporativa foi configurada. Por exemplo, um firewall em sua rede pode impedir que o tráfego externo chegue aos seus servidores. Neste caso, você tem duas opções:

  • Trabalhe com seu departamento de TI para abrir um caminho de rede entre o Azure Pipelines e o GitHub Enterprise Server. Por exemplo, você pode adicionar exceções às regras de firewall para permitir que o tráfego do Azure Pipelines flua. Consulte a seção sobre IPs do Azure DevOps para ver quais endereços IP você precisa permitir. Além disso, você precisa ter uma entrada DNS pública para o GitHub Enterprise Server para que o Azure Pipelines possa resolver o FQDN do seu servidor para um endereço IP. Com todas essas alterações, tente criar e verificar uma conexão do GitHub Enterprise Server no Azure Pipelines.

  • Em vez de usar uma conexão do GitHub Enterprise Server, você pode usar uma conexão Outro Git. Certifique-se de desmarcar a opção de Tentar acessar este servidor Git do Azure Pipelines. Com esse tipo de conexão, você só pode configurar um pipeline de build clássico. Os gatilhos de CI e PR não funcionarão nessa configuração. Você só pode iniciar execuções de pipeline manuais ou agendadas.

Acessível nos agentes hospedados pela Microsoft

Outra decisão que você possivelmente precisa tomar é usar agentes hospedados pela Microsoft ou agentes auto-hospedados para executar seus pipelines. Isso geralmente se resume a se os agentes hospedados pela Microsoft podem acessar seu servidor. Para verificar se eles podem, crie um pipeline simples para usar agentes hospedados pela Microsoft e adicione uma etapa para fazer check-out do código-fonte do servidor. Se isso for aprovado, você poderá continuar usando agentes hospedados pela Microsoft.

Não acessível por agentes hospedados pela Microsoft

Se o pipeline de teste simples mencionado na seção acima falhar com o erro TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting, o GitHub Enterprise Server não poderá ser acessado pelos agentes hospedados pela Microsoft. Novamente, isso provavelmente é causado por um firewall bloqueando o tráfego desses servidores. Neste caso, você tem duas opções:

  • Trabalhe com seu departamento de TI para abrir um caminho de rede entre os agentes hospedados pela Microsoft e o GitHub Enterprise Server. Consulte a seção sobre rede em agentes hospedados pela Microsoft.

  • Alterne para usar agentes auto-hospedados ou agentes de conjunto de dimensionamento. Esses agentes podem ser configurados em sua rede e, portanto, terão acesso ao GitHub Enterprise Server. Esses agentes exigem apenas conexões de saída com o Azure Pipelines. Não é necessário abrir um firewall para conexões de entrada. Verifique se o nome do servidor que você especificou ao criar a conexão do GitHub Enterprise Server pode ser resolvido pelos agentes auto-hospedados.

Endereços IP do Azure DevOps

O Azure Pipelines envia solicitações ao GitHub Enterprise Server para:

  • Consultar uma lista de repositórios durante a criação do pipeline (pipelines clássicos e YAML)
  • Procure arquivos YAML existentes durante a criação do pipeline (pipelines YAML)
  • Arquivos YAML de check-in (pipelines YAML)
  • Registrar um webhook durante a criação do pipeline (pipelines clássicos e YAML)
  • Apresentar um editor para arquivos YAML (pipelines YAML)
  • Resolver modelos e expandir arquivos YAML antes da execução (pipelines YAML)
  • Verificar se há alterações desde a última execução agendada (pipelines clássicos e YAML)
  • Buscar detalhes sobre a confirmação mais recente e exibir isso na interface do usuário (pipelines clássicos e YAML)

Você pode observar que os pipelines YAML exigem fundamentalmente a comunicação entre Azure Pipelines e GitHub Enterprise Server. Portanto, não é possível configurar um pipeline YAML se o GitHub Enterprise Server não estiver visível para o Azure Pipelines.

Ao usar a conexão Outro Git para configurar um pipeline clássico, desabilitar a comunicação entre o serviço Azure Pipelines e o GitHub Enterprise Server e usar agentes auto-hospedados para criar código, você obterá uma experiência degradada:

  • Você precisará digitar o nome do repositório manualmente durante a criação do pipeline
  • Você não pode usar gatilhos de CI ou PR, pois o Azure Pipelines não pode registrar um webhook no GitHub Enterprise Server
  • Você não pode usar gatilhos agendados com a opção de compilar somente quando houver alterações
  • Não é possível exibir informações sobre a confirmação mais recente na interface do usuário

Se você deseja configurar pipelines YAML ou aprimorar a experiência com pipelines clássicos, é importante habilitar a comunicação do Azure Pipelines para o GitHub Enterprise Server.

Para permitir que o tráfego do Azure DevOps alcance seu GitHub Enterprise Server, adicione os endereços IP ou marcas de serviço especificados em Conexões de entrada à lista de permissões do firewall. Se você usar o ExpressRoute, inclua também os Intervalos de IP do ExpressRoute na lista de permissões do seu firewall.

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 Enterprise se enquadram nas seguintes categorias:

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

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:

  • Os webhooks são usados para comunicar atualizações do GitHub Enterprise para o Azure Pipelines. No GitHub Enterprise, navegue até as configurações do repositório e, em seguida, para Webhooks. Verifique se os webhooks existem. Normalmente, você deve ver dois webhooks: push, pull_request. 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.

  • Selecione cada um dos webhooks no GitHub Enterprise 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.

  • 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 o GitHub Enterprise Server estiver por trás de um firewall, esse tráfego poderá não chegar ao servidor. Confira Endereços IP do Azure DevOps e verifique se você concedeu exceções a todos os endereços IP necessários. Esses endereços IP podem ter sido alterados, pois você configurou originalmente as regras de exceção.

  • 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 uma PR que não disparou um pipeline, abra-a e verifique se ela 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.
    • Sua instância do GitHub Enterprise Server pode ser subprovisionada, reduzindo a velocidade das solicitações de processamento do Azure Pipelines. Leia mais sobre considerações de hardware para o GitHub Enterprise Server.

Check-out com falha

Você usa agentes hospedados pela Microsoft? Nesse caso, esses agentes podem não conseguir acessar o GitHub Enterprise Server. Não é possível acessar agentes hospedados pela Microsoft para obter mais informações.

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.