Criar repositórios do GitHub Enterprise Server

Artigo
10/23/2023

Serviços de DevOps do Azure

Você pode integrar seu GitHub Enterprise Server local com o Azure Pipelines. Seu servidor local pode estar exposto à Internet ou pode não estar.

Se o seu GitHub Enterprise Server estiver acessível a partir dos servidores que executam o serviço Azure Pipelines, então:

você pode configurar pipelines clássicos de compilação e YAML
você pode configurar CI, RP e gatilhos agendados

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

Você só pode configurar pipelines de compilação clássicos
Você só pode iniciar compilações manuais ou agendadas
não é possível configurar pipelines YAML
não é possível configurar gatilhos de CI ou PR para seus pipelines de compilação clássicos

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

Acessível a partir dos Pipelines do Azure

A primeira coisa a verificar é se o GitHub Enterprise Server está acessível a partir do serviço Azure Pipelines.

Na interface do usuário do Azure DevOps, navegue até as configurações do projeto e selecione Conexões de Serviço em Pipelines.
Selecione Nova conexão de serviço e escolha GitHub Enterprise Server como o tipo de conexão.
Insira as informações necessárias para criar uma conexão com o GitHub Enterprise Server.
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 prosseguir e configurar a conexão. Em seguida, você pode usar essa conexão de serviço ao criar uma compilação clássica ou pipeline YAML. Você também pode configurar gatilhos de CI e PR para o pipeline. A maioria dos recursos do Azure Pipelines que funcionam com o GitHub também funciona com o GitHub Enterprise Server. Consulte 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 Azure Pipelines no mercado do GitHub. Este aplicativo permite que você configure uma integração sem ter que confiar no 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 dá 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. Não é possível usar comentários em uma solicitação pull de repositório do servidor GitHub Enterprise para disparar um pipeline.
As verificações do GitHub não estão disponíveis no servidor GitHub Enterprise. Todas as atualizações de status são através de status básicos.

Não acessível a partir dos Pipelines do Azure

Quando a verificação de uma conexão do GitHub Enterprise Server, conforme explicado na seção acima, falhar, os Pipelines do Azure não poderão se comunicar com seu servidor. Isso provavelmente é causado pela forma como a rede corporativa está configurada. Por exemplo, um firewall na sua rede pode impedir que o tráfego externo chegue aos seus servidores. Neste caso, 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 suas regras de firewall para permitir que o tráfego dos Pipelines do Azure flua. Consulte a seção sobre IPs de DevOps do Azure 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 Other Git. Certifique-se de desmarcar a opção para Tentar acessar este servidor Git do Azure Pipelines. Com esse tipo de conexão, você só pode configurar um pipeline de compilação clássico. Os gatilhos de CI e PR não funcionarão nesta configuração. Você só pode iniciar execuções de pipeline manuais ou agendadas.

Acessível a partir de agentes hospedados pela Microsoft

Outra decisão que você possivelmente terá que tomar é se deve usar agentes hospedados pela Microsoft ou agentes auto-hospedados para executar seus pipelines. Isso geralmente se resume a saber 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 certifique-se de adicionar uma etapa para fazer check-out do código-fonte do seu servidor. Se isso passar, você poderá continuar usando agentes hospedados pela Microsoft.

Não acessível a partir de 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 a partir de agentes hospedados pela Microsoft. Isso é novamente provavelmente causado por um firewall bloqueando o tráfego desses servidores. Neste caso, tem duas opções:

Trabalhe com seu departamento de TI para abrir um caminho de rede entre agentes hospedados pela Microsoft e o GitHub Enterprise Server. Consulte a seção sobre rede em agentes hospedados pela Microsoft.
Mude para o uso de agentes auto-hospedados ou agentes de scale-set. 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 há necessidade de abrir um firewall para conexões de entrada. Certifique-se de que o nome do servidor especificado ao criar a conexão do GitHub Enterprise Server possa ser resolvido a partir dos agentes auto-hospedados.

Endereços IP do Azure DevOps

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

Consulta de uma lista de repositórios durante a criação de pipeline (pipelines clássicos e YAML)
Procure arquivos YAML existentes durante a criação do pipeline (pipelines YAML)
Check-in de arquivos YAML (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)
Verifique se há alguma alteração desde a última execução agendada (pipelines clássicos e YAML)
Buscar detalhes sobre a confirmação mais recente e exibi-los na interface do usuário (pipelines clássicos e YAML)

Você pode observar que os pipelines YAML exigem fundamentalmente comunicação entre o Azure Pipelines e o 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.

Quando você usa Outra conexão Git para configurar um pipeline clássico, desabilita a comunicação entre o serviço Azure Pipelines e o GitHub Enterprise Server e usa agentes auto-hospedados para criar código, você terá uma experiência degradada:

Você terá que digitar o nome do repositório manualmente durante a criação do pipeline
Não é possível usar gatilhos de CI ou PR, pois o Azure Pipelines não pode registrar um webhook no GitHub Enterprise Server
Não é possível usar gatilhos agendados com a opção de criar 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ê quiser configurar pipelines YAML ou se quiser 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 chegue ao seu GitHub Enterprise Server, adicione os endereços IP ou tags de serviço especificados em Conexões de entrada à lista de permissões do firewall. Se você usa a Rota Expressa, certifique-se de incluir também os intervalos de IP da Rota Expressa na lista de permissões do 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 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 extensões e inclusão de 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 configuração Ramificação padrão para compilações manuais e agendadas ou ao escolher uma ramificação ao executar um pipeline manualmente. Se você não vir a ramificação desejada na lista, digite o nome da ramificação desejada manualmente.

FAQ

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

Gatilhos com falha: Meu pipeline não está sendo acionado quando envio uma atualização para o repositório.
Falha no check-out: 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.

Gatilhos com falha

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

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

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

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

Webhooks são usados para comunicar atualizações do GitHub Enterprise para o Azure Pipelines. No GitHub Enterprise, navegue até as configurações do repositório e, em seguida, até Webhooks. Verifique se os webhooks existem. Normalmente, você deve ver dois webhooks - push, pull_request. 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.
Selecione cada um dos webhooks no GitHub Enterprise e verifique se a carga útil que corresponde à confirmação do usuário existe e foi enviada com êxito para o Azure DevOps. Você poderá ver 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 protegido por um firewall, esse tráfego pode não chegar ao seu servidor. Consulte 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 desde que você configurou originalmente as regras de exceção.

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 PR que não acionou um pipeline, abra-o e verifique se ele tem um conflito de mesclagem. Resolva o conflito de mesclagem.
Você está enfrentando um atraso no processamento de eventos 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.
- Sua instância do GitHub Enterprise Server pode estar subprovisionada, atrasando o processamento de solicitações do Azure Pipelines. Leia mais sobre considerações de hardware para o GitHub Enterprise Server.

Falha no checkout

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

Versão errada

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

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