Esta versão do GitHub Enterprise Server foi descontinuada em 2024-09-25. Nenhum lançamento de patch será feito, mesmo para questões críticas de segurança. Para obter melhor desempenho, segurança aprimorada e novos recursos, atualize para a última versão do GitHub Enterprise Server. Para obter ajuda com a atualização, entre em contato com o suporte do GitHub Enterprise.

Solucionar problemas no GitHub Actions para a sua empresa

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

Quem pode usar esse recurso?

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

Neste artigo

Verificando a saúde de GitHub Actions

Verifique a integridade do GitHub Actions em sua instância do GitHub Enterprise Server com o utilitário de linha de comando ghe-actions-check. Para obter mais informações, confira "Utilitários de linha de comando" e "Acesar 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 saber mais, confira "Configurar o 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 que o aplicativo do executor auto-hospedado use o certificado, você precisa definir a variável de ambiente NODE_EXTRA_CA_CERTS no computador do executor.

Você pode definir a variável de ambiente como uma variável de ambiente do sistema ou declará-la em um arquivo chamado .env no diretório do aplicativo executor auto-hospedado (ou seja, o diretório no qual você baixou e descompactou o software executor).

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 no GitHub:

  • Você deve adicionar .localhost, 127.0.0.1 e ::1 à lista de Exclusão de Proxy HTTP (nessa ordem).
  • Se o local de armazenamento externo não for encaminhável, você também precisará adicionar a URL de armazenamento externo à lista de exclusões.

Para obter mais informações sobre como alterar as configurações de proxy, confira "Configurando um servidor proxy Web de saída".

Se essas configurações não estiverem definidas corretamente, você poderá receber erros como Resource unexpectedly moved to https://IP-ADDRESS ao definir ou alterar sua configuração do 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 do GitHub Enterprise Server após a configuração inicial. Alterar o nome do host causará comportamento inesperado, até e incluindo falhas de instância e invalidação das chaves de segurança dos usuários. Se você alterou o nome do host da instância e está enfrentando problemas, entre em contato com Suporte do GitHub Enterprise ou Suporte do GitHub Premium.

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 executores auto-hospedados para usar o novo nome de host de sua instância do GitHub Enterprise Server. Cada executor auto-hospedado exigirá um dos seguintes procedimentos:

  • No diretório do aplicativo do executor auto-hospedado, edite os arquivos .runner e .credentials para substituir todas as menções do nome do host antigo pelo novo nome do 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, confira "Remover executores auto-hospedados" e "Adicionar executores auto-hospedados."

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

O GitHub Actions é composto por vários serviços em execução em sua instância do GitHub Enterprise Server. 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. Verificar o uso total da CPU e de 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, confira "About the monitor dashboard".

Se o uso da CPU geral em "Integridade do Sistema" estiver próximo a 100% ou se não houver mais memória disponível, a sua instância do GitHub Enterprise Server será executada dentro da capacidade e precisará ser escalada verticalmente. Para obter mais informações, confira "Aprimorar os recursos de CPU ou memória".

2. Verificar o uso da CPU e de memória dos trabalhos do 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. Aumentar a alocação de recurso para serviços no limite

  1. Efetue o login no shell administrativo usando SSH. Para obter mais informações, confira "Acesar 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". Ele é semelhante ao exemplo a seguir:

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

    Para a CPU e a memória, isso mostra a quantidade alocada ao total de todos os serviços (o valor à esquerda) e a quantidade que está disponível (o valor à direita). 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.

    Warning

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

  3. Altere o diretório para /etc/consul-templates/etc/nomad-jobs/actions:

    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 resources que se parece com o seguinte:

    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 feche o arquivo.

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

    Ao executar ghe-config-apply, se você observar uma saída como Failed to run nomad job '/etc/nomad-jobs/<name>.hcl', a alteração provavelmente terá recursos de CPU ou de memória alocados em excesso. Se isso acontecer, edite os arquivos de configuração novamente, reduza a CPU ou a memória alocada e execute ghe-config-apply novamente.

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

Solucionar problemas de falhas quando Dependabot dispara fluxos de trabalho existentes

Depois de configurar as atualizações do Dependabot para sua instância do GitHub Enterprise Server, você poderá ver as falhas quando os fluxos de trabalho existentes forem disparados por eventos do Dependabot.

Por padrão, as execuções de fluxo de trabalho do GitHub Actions disparadas pelo Dependabot dos eventos push, pull_request, pull_request_review ou pull_request_review_comment são tratados como se eles fossem abertos de um fork do repositório. Ao contrário dos fluxos de trabalho disparados por outros atores, isso significa que eles recebem o GITHUB_TOKEN somente leitura e não têm acesso a nenhum segredo que esteja normalmente disponível. Isso fará com que quaisquer fluxos de trabalho que tentam gravar no repositório falhem quando forem acionados por Dependabot.

Há três maneiras de resolver este problema:

  1. Você pode atualizar seus fluxos de trabalho para que não sejam mais disparados pelo Dependabot usando uma expressão como: if: github.actor != 'dependabot[bot]'. Para obter mais informações, confira "Avaliar expressões em fluxos de trabalho e ações".
  2. Modifique seus fluxos de trabalho para usar um processo de duas etapas que inclui pull_request_target que não tem essas limitações. Para obter mais informações, confira "Automatizando o Dependabot com GitHub Actions".
  3. Forneça fluxos de trabalho disparados pelo acesso do Dependabot aos segredos e permita que o termo permissions aumente o escopo padrão do GITHUB_TOKEN. Para obter mais informações, confira "Como fornecer fluxos de trabalho disparados pelo acesso do Dependabot aos segredos e às permissões aumentadas" abaixo.

Fornecendo fluxos de trabalho acionados pelo acesso de Dependabot a segredos e permissões ampliadas

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

  2. Para remover as limitações dos fluxos de trabalho disparados pelo Dependabot em sua instância do GitHub Enterprise Server, use o comando a seguir.

    ghe-config app.actions.disable-dependabot-enforcement true

  3. Aplicar a configuração.

    ghe-config-apply

  4. Volte para o GitHub Enterprise Server.

Solucionando problemas das ações agrupadas em GitHub Actions

Se você receber o erro a seguir ao instalar o GitHub Actions no GitHub Enterprise Server, você poderá resolver o problema instalando as ações oficiais empacotadas e os modelos de fluxo de trabalho.

A part of the Actions setup had problems and needs an administrator to resolve.

Para instalar as ações oficiais empacotadas e os modelos de fluxo de trabalho dentro de uma organização designada no GitHub Enterprise Server, siga este procedimento.

  1. Identifique uma organização que armazenará as ações oficiais agrupadas e os modelos de fluxo de trabalho. Você pode criar uma nova organização ou reutilizar uma já existente.

  2. Efetue o login no shell administrativo usando SSH. Para obter mais informações, confira "Acesar o shell administrativo (SSH)".

  3. Para designar sua organização como o local para armazenar as ações agrupadas, use o comando ghe-config, substituindo ORGANIZATION pelo nome da sua organização.

    ghe-config app.actions.actions-org ORGANIZATION

    e:

    ghe-config app.actions.github-org ORGANIZATION

  4. Para adicionar as ações empacotadas à sua organização, cancele a definição do SHA.

    ghe-config --unset 'app.actions.actions-repos-sha1sum'

  5. Aplicar a configuração.

    ghe-config-apply

Depois de concluir essas etapas, retome a configuração do GitHub Actions em "Primeiros passos com o GitHub Actions para o GitHub Enterprise Server".