Skip to main content
Publicamos atualizações frequentes em nossa documentação, e a tradução desta página ainda pode estar em andamento. Para obter as informações mais recentes, acesse a documentação em inglês. Se houver problemas com a tradução desta página, entre em contato conosco.

Esta versão do GitHub Enterprise foi descontinuada em 2022-06-03. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, melhorar a segurança e novos recursos, upgrade to the latest version of GitHub Enterprise. Para ajuda com a atualização, contact GitHub Enterprise support.

Solucionar problemas no GitHub Actions para a sua empresa

Solucionar problemas comuns que ocorrem ao usar GitHub Actions em GitHub Enterprise Server.

Site administrators can troubleshoot GitHub Actions issues and modify GitHub Enterprise Server configurations.

Verificando a saúde de GitHub Actions

Você pode verificar a saúde de GitHub Actions em your GitHub Enterprise Server instance com o utilitário da linha de comando ghe-actions-check. Para obter mais informações, consulte "Utilitários de linha de comando" e "Acessando o shell administrativo (SSH)".

Configurar executores auto-hospedados ao usar um certificado autoassinado por GitHub Enterprise Server

É altamente recomendável que você configure a TLS em GitHub Enterprise Server com um certificado assinado por uma autoridade confiável. Embora um certificado autoassinado possa funcionar, é necessária uma configuração extra para os seus executores auto-hospedados, e não é recomendado para ambientes de produção. Para obter mais informações, consulte "Configurar TLS".

Instalar o certificado na máquina do executor

Para um executor auto-hospedado conectar-se a um GitHub Enterprise Server usando um certificado autoassinado, você deverá instalar o certificado na máquina do executor para que a conexão seja mais rígida.

Para as etapas necessárias para instalar um certificado, consulte a documentação do sistema operacional do seu executor.

Configurar o Node.JS para usar o certificado

A maioria das ações são escritas em JavaScript e são executadas usando Node.js, que não usa o armazenamento de certificados do sistema operacional. Para o aplicativo runner auto-hospedado usar o certificado, você deve definir a variável de ambiente NODE_EXTRA_CA_CERTS na máquina do executor.

Você pode definir a variável de ambiente como uma variável de ambiente do sistema, ou declará-la em um arquivo denominado .env no diretório do aplicativo do executor auto-hospedado.

Por exemplo:

NODE_EXTRA_CA_CERTS=/usr/share/ca-certificates/extra/mycertfile.crt

As variáveis de ambiente são lidas quando o aplicativo do executor auto-hospedado é iniciado. Portanto, você deve definir a variável de ambiente antes de configurar ou iniciar o aplicativo do executor auto-hospedado. Se a sua configuração de certificado for alterada, você deverá reiniciar o aplicativo do executor auto-hospedado.

Configurar contêineres do Docker para usar o certificado

Se você usa ações do contêiner do Docker ou contêineres de serviço nos seus fluxos de trabalho, você também deverá instalar o certificado na sua imagem do Docker, além de definir a variável de ambiente acima.

Configurar as definições de proxy HTTP para GitHub Actions

Se você tiver um Servidor Proxy HTTP configurado em your GitHub Enterprise Server instance, você deverá adicionar localhost e 127..0.1 �  lista HTTP Proxy Exclusion. Para obter mais informações sobre como alterar as configurações de proxy, consulte "Configurar um servidor de proxy web de saída".

Se estas configurações não estiverem definidas corretamente, você poderá receber erros como Recurso movido inesperadamente para https://<IP_ADDRESS> ao definir ou mudar a configuração de GitHub Actions.

Os executores não se conectam a GitHub Enterprise Server com um novo nome de host

Aviso: Não altere o nome do host para GitHub Enterprise Server após a configuração inicial. Alterar o nome do host causará comportamento inesperado, até e incluindo falhas de instância.

Se você implantar GitHub Enterprise Server no seu ambiente com um novo nome de host e o antigo nome de host não resolver mais a sua instância, os executores auto-hospedados não conseguirão conectar-se ao nome de host antigo e não executarão nenhum trabalho.

Você precisará atualizar a configuração dos seus executores auto-hospedados para usar o novo nome de host para your GitHub Enterprise Server instance. Cada executor auto-hospedado exigirá um dos seguintes procedimentos:

  • No diretório de do aplicativo do executor auto-hospedado, edite os arquivos de .runner e .credentials para substituir todas as menções do nome de host antigo pelo novo nome de host. Em seguida, reinicie o aplicativo do executor auto-hospedado.
  • Remova o executor de GitHub Enterprise Server usando a interface do usuário e adicione-o novamente. Para obter mais informações, consulte "Removendo os executores auto-hospedados" e "Adicionando executores auto-hospedados".

Trabalhos travados e limites de CPU e de memória das GitHub Actions

GitHub Actions é composto de vários serviços em execução em your GitHub Enterprise Server instance. Por padrão, esses serviços são configurados com limites padrão de CPU e memória que devem funcionar para a maioria das instâncias. No entanto, usuários assíduos de GitHub Actions talvez precisem para ajustar essas configurações.

É possível que você atinja o limite de CPU ou memória se você notar que os trabalhos não estão sendo iniciados (ainda que existam executores inativos), ou se o progresso do trabalho não estiver sendo atualizado ou alterando na interface do usuário.

1. Verifique o uso total da CPU e memória no console de gerenciamento

Acesse o console de gerenciamento e use o painel do monitor para inspecionar os gráficos gerais de CPU e memória em "Saúde do Sistema". Para obter mais informações, consulte "Acessar o painel do monitor".

Se o uso geral de "Saúde do Sistema" da CPU estiver próximo a 100% ou não houver mais memória livre, your GitHub Enterprise Server instance será executado na capacidade e precisará ser dimensionado. Para obter mais informações, consulte "Increasing CPU or memory resources."

2. Verifique o uso de CPU e a memória dos trabalhos Nomad no console de gerenciamento

Se a "Saúde do Sistema" para o uso total da CPU e da memória estiver OK, acesse a seção "Trabalhos Normad" na parte inferior do painel e observe os gráficos "Valor porcentual da CPU" e "Uso da memória".

Cada seção nesses gráficos corresponde a um serviço. Para os serviços de GitHub Actions, busque:

  • mps_frontend
  • mps_backend
  • token_frontend
  • token_backend
  • actions_frontend
  • actions_backend

Se qualquer um destes serviços estiver em ou perto de 100% de utilização da CPU ou se a memória estiver próxima do seu limite (2 GB por padrão), talvez seja necessário aumentar a atribuição de recursos para estes serviços. Tome nota de quais dos serviços acima estão no ou próximo do seu limite.

3. Aumenta a alocação de recursos para serviços em seu limite

  1. Efetue o login no shell administrativo usando SSH. Para obter mais informações, consulte "Acessar o shell administrativo (SSH)".

  2. Execute o comando a seguir para ver quais recursos estão disponíveis para alocação:

    nomad node status -self

    Na saída, encontre a seção "Recursos alocados". É algo parecido com o exemplo a seguir:

    Allocated Resources
    CPU              Memory          Disk
    7740/49600 MHZ   23 GiB/32 GiB   4.4 GiB/7.9 GiB
    

    Para a memória e a CPU, isso mostra quanto é alocado para o total de todos serviços (o valor �  esquerda) e quanto está disponível (o valor correto). No exemplo acima, há 23 GiB de memória alocado para um total de 32 GiB. Isto significa que há 9 GiB de memória disponíveis para atribuição.

    Aviso: Tenha cuidado para não alocar mais do que o total de recursos disponíveis, ou os serviços não poderão ser iniciados.

  3. Mude o diretório para /etc/consul-templates/etc/nomad-jobs/ações:

    cd /etc/consul-templates/etc/nomad-jobs/actions

    Neste diretório existem três arquivos que correspondem aos serviços de GitHub Actions descritos anteriormente:

    • mps.hcl.ctmpl
    • token.hcl.ctmpl
    • actions.hcl.ctmpl
  4. Para os serviços que você identificou que precisam de ajuste, abra o arquivo correspondente e localize o grupo de recursos que se parece com o exemplo a seguir:

    resources {
      cpu = 512
      memory = 2048
      network {
        port "http" { }
      }
    }
    

    Os valores estão em MHz para recursos de CPU e em MB para recursos de memória.

    Por exemplo, para aumentar os limites de recursos no exemplo acima para 1 GHz para a CPU e 4 GB de memória, altere-os para:

    resources {
      cpu = 1024
      memory = 4096
      network {
        port "http" { }
      }
    }
    
  5. Salve e saia do arquivo.

  6. Execute o ghe-config-apply para aplicar as alterações.

    Ao executar ghe-config-apply, se você vir a saída como Failed to run nomad job '/etc/nomad-jobs/<name>.hcl', a mudança provavelmente atribuiu muitos recursos de CPU ou memória. Se isso acontecer, edite os arquivos de configuração novamente e baixe a CPU ou memória alocados e execute ghe-config-apply novamente.

  7. Depois que a configuração for aplicada, execute ghe-actions-check para verificar se os serviços GitHub Actions estão operando.