Monitorar e solucionar problemas de executores auto-hospedados

Como usar executores auto-hospedados no nível do repositório

Talvez você não consiga criar um executor auto-hospedado para um repositório de propriedade da organização.

Proprietários de empresas e organizações podem escolher que repositórios têm permissão para criar executores auto-hospedados no nível do repositório. Usuários com a permissão "Gerenciar executores e grupos de executores da organização" só podem escolher quais repositórios têm permissão para criar executores auto-hospedados no nível do repositório para repositórios em sua organização.

Para obter mais informações sobre funções de organização personalizadas, consulte "Sobre as funções da organização personalizadas".

Para obter mais informações, confira "Aplicando políticas para o GitHub Actions na sua empresa" e "Desabilitar ou limitar o GitHub Actions para sua organização".

Como verificar o status de um executor auto-hospedado

Um executor auto-hospedado pode estar localizado no repositório, na organização ou nas configurações da empresa do GitHub Enterprise Server. Para gerenciar um executor auto-hospedado, você deve ter as seguintes permissões, dependendo de onde o executor auto-hospedado foi adicionado:

• Repositório do usuário: você precisa ser o proprietário do repositório.

• Organização: você precisa ser um proprietário da organização.

• Repositório da organização: você precisa ser um proprietário da organização ou ter acesso de administrador no repositório.

• Empresa: você precisa ser um administrador do site do GitHub Enterprise.

1. Na sua organização ou no seu repositório, navegue até a página principal e clique em Configurações.

2. Na barra lateral esquerda, clique em Ações e clique em Executores.

3. Em "Executores", você pode ver uma lista de executores registrados, incluindo o nome, etiqueta e status do executor.

   O status pode ser um dos seguintes:

   • Ocioso: o executor está conectado ao GitHub Enterprise Server e está pronto para executar trabalhos.
   • Ativo: o executor está executando um trabalho no momento.
   • Offline: o executor não está conectado ao GitHub Enterprise Server. Isto pode ser porque a máquina está off-line, o aplicativo do executor auto-hospedado não está funcionando na máquina, ou o aplicativo do executor auto-hospedado não pode comunicar-se com GitHub Enterprise Server.

Solução de problemas da conectividade de rede

Verificando conectividade de rede do executor auto-hospedado

Use o script config do aplicativo do executor auto-hospedado com o parâmetro --check para verificar se um executor auto-hospedado pode acessar todos os serviços de rede necessários no GitHub.

Além de --check, você precisa fornecer dois argumentos para o script:

• --url pela URL para o repositório do repositório, da organização ou da empresa do GitHub. Por exemplo, --url https://github.com/octo-org/octo-repo.
• --pat com o valor de um personal access token (classic), que precisa ter o escopo workflow ou um fine-grained personal access token com acesso de leitura e gravação em fluxos de trabalho. Por exemplo, --pat ghp_abcd1234. Para obter mais informações, confira "Gerenciar seus tokens de acesso pessoal".

Por exemplo:

./config.sh --check --url URL --pat ghp_abcd1234

./config.sh --check --url URL --pat ghp_abcd1234

config.cmd --check --url https://github.com/YOUR-ORG/YOUR-REPO --pat GHP_ABCD1234

O script testa cada serviço e gera um PASS ou um FAIL para cada um. Se você tiver alguma verificação com falha, você pode ver mais detalhes sobre o problema no arquivo de registro para a verificação. Os arquivos de log estão localizados no diretório _diag em que você instalou o aplicativo do executor, e o caminho do arquivo de log para cada verificação é mostrado na saída do console do script.

Se você tiver alguma verificação com falha, você deve também verificar se a sua máquina de executores auto-hospedada cumpre todos os requisitos de comunicação. Para obter mais informações, confira "Sobre executores auto-hospedados".

Desabilitando verificação de certificado TLS

Por padrão, o aplicativo do executor auto-hospedado verifica o certificado TLS do GitHub Enterprise Server. Se o seu GitHub Enterprise Server tiver um certificado autoassinado ou emitido internamente, você deverá desabilitar a verificação de certificado TLS para fins de teste.

Para desabilitar a verificação de certificação TLS no aplicativo do executor auto-hospedado, defina a variável de ambiente GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY como 1 antes de configurar e executar o aplicativo do executor auto-hospedado.

export GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY=1
./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO --token
./run.sh

export GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY=1
./config.sh --url https://github.com/YOUR-ORG/YOUR-REPO --token
./run.sh

[Environment]::SetEnvironmentVariable('GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY', '1')
./config.cmd --url https://github.com/YOUR-ORG/YOUR-REPO --token
./run.cmd

Revisar os arquivos de registro do aplicativo do executor auto-hospedado

Você pode monitorar o status do aplicativo do executor auto-hospedado e suas atividades. Os arquivos de log são mantidos no diretório _diag em que você instalou o aplicativo do executor, e um novo log é gerado sempre que o aplicativo é iniciado. O nome do arquivo começa com Runner_ e é seguido de um carimbo de data/hora UTC de quando o aplicativo é iniciado.

Para obter logs detalhados sobre as execuções de tarefa de fluxo de trabalho, confira a próxima seção que descreve os arquivos Worker_.

Revisar o arquivo de registro de um trabalho

O aplicativo do executor auto-hospedado cria um arquivo de registro detalhado para cada trabalho que processa. Esses arquivos são armazenados no diretório _diag em que você instalou o aplicativo do executor, e o nome do arquivo começa com Worker_.

$ cat ~/actions-runner/.service
actions.runner.octo-org-octo-repo.runner01.service

$ systemctl --type=service | grep actions.runner
actions.runner.octo-org-octo-repo.hostname.service loaded active running GitHub Actions Runner (octo-org-octo-repo.hostname)

sudo journalctl -u actions.runner.octo-org-octo-repo.runner01.service -f

Feb 11 14:57:07 runner01 runsvc.sh[962]: Starting Runner listener with startup type: service
Feb 11 14:57:07 runner01 runsvc.sh[962]: Started listener process
Feb 11 14:57:07 runner01 runsvc.sh[962]: Started running service
Feb 11 14:57:16 runner01 runsvc.sh[962]: √ Connected to GitHub
Feb 11 14:57:17 runner01 runsvc.sh[962]: 2020-02-11 14:57:17Z: Listening for Jobs
Feb 11 16:06:54 runner01 runsvc.sh[962]: 2020-02-11 16:06:54Z: Running job: testAction
Feb 11 16:07:10 runner01 runsvc.sh[962]: 2020-02-11 16:07:10Z: Job testAction completed with result: Succeeded

% cat ~/actions-runner/.service
/Users/exampleUsername/Library/LaunchAgents/actions.runner.octo-org-octo-repo.runner01.plist

$ ./svc.sh status
status actions.runner.example.runner01:
/Users/exampleUsername/Library/LaunchAgents/actions.runner.example.runner01.plist
Started:
379 0 actions.runner.example.runner01

PS C:\actions-runner> Get-Content .service
actions.runner.octo-org-octo-repo.runner01.service

PS C:\actions-runner> Get-Service "actions.runner.octo-org-octo-repo.runner01.service" | Select-Object Name, Status
Name                                                  Status
----                                                  ------
actions.runner.octo-org-octo-repo.runner01.service    Running

PS C:\actions-runner> Get-EventLog -LogName Application -Source ActionsRunnerService

   Index Time          EntryType   Source                 InstanceID Message
   ----- ----          ---------   ------                 ---------- -------
     136 Mar 17 13:45  Information ActionsRunnerService          100 2020-03-17 13:45:48Z: Job Greeting completed with result: Succeeded
     135 Mar 17 13:45  Information ActionsRunnerService          100 2020-03-17 13:45:34Z: Running job: testAction
     134 Mar 17 13:41  Information ActionsRunnerService          100 2020-03-17 13:41:54Z: Listening for Jobs
     133 Mar 17 13:41  Information ActionsRunnerService          100 û Connected to GitHub
     132 Mar 17 13:41  Information ActionsRunnerService            0 Service started successfully.
     131 Mar 17 13:41  Information ActionsRunnerService          100 Starting Actions Runner listener
     130 Mar 17 13:41  Information ActionsRunnerService          100 Starting Actions Runner Service
     129 Mar 17 13:41  Information ActionsRunnerService          100 create event log trace source for actions-runner service

Monitorar o processo de atualização automática

Recomendamos que você verifique regularmente o processo de atualização automática, uma vez que o executor auto-hospedado não será capaz de processar os trabalhos se estiver abaixo de um determinado limite de versão. O aplicativo do executor auto-hospedado atualiza-se, mas mas observe que este processo não inclui atualizações do sistema operacional ou de outro software. Será necessário que você gerencie essas atualizações separadamente.

Você pode ver as atividades de atualização nos arquivos de log Runner_. Por exemplo:

[Feb 12 12:37:07 INFO SelfUpdater] An update is available.

Além disso, encontre mais informações nos arquivos de log SelfUpdate localizados no diretório _diag em que você instalou o aplicativo do executor.

$ sudo systemctl is-active docker.service
active

[2020-02-13 16:56:10Z INFO DockerCommandManager] Which: 'docker'
[2020-02-13 16:56:10Z INFO DockerCommandManager] Not found.
[2020-02-13 16:56:10Z ERR  StepsRunner] Caught exception from step: System.IO.FileNotFoundException: File not found: 'docker'

dial unix /var/run/docker.sock: connect: permission denied

$ sudo systemctl show -p User actions.runner.octo-org-octo-repo.runner01.service
User=runner-user

Resolver os executores que estiverem offline após uma atualização de GitHub Enterprise Server

Se você usar executores efêmeros e tiver desabilitado as atualizações automáticas, para atualizar o GitHub Enterprise Server, primeiro você deverá atualizar os executores auto-hospedados para a versão do aplicativo executor que sua instância atualizada executará. A atualização do GitHub Enterprise Server antes de atualizar os executores efêmeros poderá fazer com que os executores fiquem offline. Para obter mais informações, confira "Visão geral do processo de atualização".

Se os executores estiverem offline por esse motivo, atualize-os manualmente. Para saber mais, confira as instruções de instalação para a versão mais recente no repositório ações/executor.

Verificando qual mecanismo do Docker está instalado no executor

Se seu build falhar com o seguinte erro:

Error: Input required and not supplied: java-version

Verifique qual mecanismo do Docker está instalado no executor auto-hospedado. Para passar as entradas de uma ação para o contêiner do Docker, o executor usa variáveis de ambiente cujos nomes podem conter traços. A ação talvez não consiga obter as entradas se o mecanismo do Docker não for um executável binário, mas, em vez disso, for um wrapper de shell ou um link (por exemplo, um mecanismo do Docker instalado no Linux usando snap). Para resolver esse erro, configure seu executor auto-hospedado para usar um mecanismo diferente do Docker.

Para verificar se o mecanismo do Docker foi instalado usando o snap, use o comando which. No seguinte exemplo, o mecanismo do Docker foi instalado usando o snap:

$ which docker
/snap/bin/docker