Esta versão do GitHub Enterprise foi descontinuada em 2021-09-23. 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.

Monitoramento e resolução de problemas dos executores auto-hospedados

Você pode monitorar seus executores auto-hospedados para visualizar sua atividade e diagnosticar problemas comuns.

Observação: GitHub Actions estava disponível para GitHub Enterprise Server 2.22 como um beta limitado. O beta terminou. GitHub Actions está agora geralmente disponível em GitHub Enterprise Server 3.0 ou posterior. Para obter mais informações, consulte as observações sobre a versão GitHub Enterprise Server 3.0.


Observação: Executores hospedados em GitHub não são atualmente compatíveis com GitHub Enterprise Server. Você pode ver mais informações sobre suporte futuro planejado no Itinerário público do GitHub.

Verificar o status de um executor auto-hospedado usando GitHub

Um executor auto-hospedado pode ser localizado no seu repositório, organização, ou configurações corporativas em sua instância 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 de Usuário: Você deve ser o proprietário do repositório.

  • Organização: Você deve ser um proprietário da organização.

  • Repositório da organização: Você deve ser o proprietário da organização ou ter acesso de administrador ao repositório.

  • Empresa: Você deve ser um administrador do site de GitHub Enterprise

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

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

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

    Pode haver os seguintes status:

    • Inativo: O executor está conectado a GitHub Enterprise Server e está pronto para executar trabalhos.
    • Ativo: O executor está executando uma tarefa no momento.
    • Off-line: O executor não está conectado a 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.

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 registro são mantidos no diretório _diag e um novo é gerado toda vez que o aplicativo é iniciado. O nome do arquivo começa com Runner_, e é seguido por uma marca de tempo de UTC para quando o aplicativo foi iniciado.

Para obter registros detalhados sobre as execuções do fluxo de trabalho, consulte a próxima seção que escreve 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 e o nome do arquivo começa com Worker_.

Usar journalctl para verificar o serviço do aplicativo do executor auto-hospedado

Para os executores auto-hospedados baseados no Linux que executam o aplicativo usando um serviço, você pode usar o journalctl para monitorar a sua atividade em tempo real. O serviço-padrão baseado no sistema usa a seguinte convenção de nomes: actions.runner.<org>-<repo>.<runnerName>.service. Esse nome será truncado se exceder 80 caracteres. Portanto, a forma preferida de encontrar o nome do serviço é selecionar o arquivo .service. Por exemplo:

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

Você pode usar o journalctl para monitorar a atividade em tempo real do executor auto-hospedado:

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

Neste exemplo de saída, você pode ver o início runner01, receber um trabalho denominadotestAction e, em seguida, exibir o status resultante:

Feb 11 14:57:07 runner01 runsvc.sh[962]: Iniciando o ouvinte do executor com o tipo de inicialização: serviço
Feb 11 14:57:07 runner01 runsvc.sh[962]: Processo do ouvinte iniciado
Feb 11 14:57:07 runner01 runsvc.sh[962]: Serviço de execução iniciado
Feb 11 14:57:16 runner01 runsvc.sh[962]: √ Conectado ao GitHub
Feb 11 14:57:17 runner01 runsvc.sh[962]: 2020-02-11 14:57:17Z: Escuta para Jobs
Feb 11 16:06:54 runner01 runsvc.sh[962]: 2020-02-11 16:06:54Z: Trabalho em execução: testAction
Feb 11 16:07:10 runner01 runsvc.sh[962]: 2020-02-11 16:07:10Z: Trabalho testAction concluído com o resultado: Aprovado

Para visualizar a configuração do systemd, você pode localizar o arquivo de serviço aqui: /etc/systemd/system/actions.runner.<org>-<repo>.<runnerName>.service. Se você desejar personalizar o serviço de aplicação do executor auto-hospedado, não modifique esse arquivo diretamente. Siga as instruções descritas em "Configurar o aplicativo do executor auto-hospedado como um serviço".

Usar o launchd para verificar o serviço do aplicativo do executor auto-hospedado

Para executores auto-hospedados baseados em macOS que executam o aplicativo como um serviço, você pode usar o launchctl para monitorar suas atividades em tempo real. O serviço-padrão baseado no launchd usa a seguinte convenção de nomes: actions.runner.<org>-<repo>.<runnerName>. Esse nome será truncado se exceder 80 caracteres. Portanto, a forma preferida de encontrar o nome do serviço será selecionar o arquivo .service no diretório do executor:

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

O script svc.sh usa launchctl para verificar se o aplicativo está sendo executado. Por exemplo:

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

A saída resultante inclui o ID do processo e o nome do serviço de launchd do aplicativo.

Para visualizar a configuração do launchd, você pode localizar o arquivo de serviço aqui: /Users/exampleUsername/Library/LaunchAgents/actions.runner.<repoName>.<runnerName>.service. Se você desejar personalizar o serviço de aplicação do executor auto-hospedado, não modifique esse arquivo diretamente. Siga as instruções descritas em "Configurar o aplicativo do executor auto-hospedado como um serviço".

Usar PowerShell para verificar o serviço do aplicativo do executor auto-hospedado

Para executores auto-hospedados baseados no Windows que executam o aplicativo como um serviço, você pode usar o PowerShell para monitorar suas atividades em tempo real. O serviço usa a convenção de nome GitHub Actions Runner (<org>-<repo>.<runnerName>). Você também pode encontrar o nome do serviço, verificando o arquivo .service no diretório do executor:

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

Você pode visualizar o status do executor no aplicativo Services no Windows (services.msc). Você também pode usar o PowerShell para verificar se o serviço está sendo executado:

PS C:\actions-runner> Get-Service "actions.runner.octo-org-octo-repo.runner01.service" | Select-Object Name, Status
Nome                                                  Status
----                                                  ------
actions.runner.octo-org-octo-repo.runner01.service    Em execução

Você pode usar o PowerShell para verificar a atividade recente do executor auto-hospedado. Neste exemplo de saída, você pode ver o início do aplicativo, receba um trabalho denominado testAction e, em seguida, exiba o status resultante:

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

   Índice temporal          Tipo de entrada   Fonte                 ID da instância Mensagem
   ----- ----          ---------   ------                 ---------- -------
     136 Mar 17 13:45  Informação ActionsRunnerService          100 2020-03-17 13:45:48Z: Job Saudação concluída com o resultado: Aprovado
     135 Mar 17 13:45  Informação ActionsRunnerService          100 2020-03-17 13:45:34Z: Trabalho em execução: testAction
     134 Mar 17 13:41  Informação ActionsRunnerService          100 2020-03-17 13:41:54Z: Escuta para trabalhos
     133 Mar 17 13:41  Informação ActionsRunnerService          100 û conectado ao GitHub
     132 Mar 17 13:41  Informação ActionsRunnerService            0 Service iniciado com sucesso.
     131 Mar 17 13:41  Informação ActionsRunnerService          100 Iniciando ações do ouvinte do executor
     130 Mar 17 13:41  Informação ActionsRunnerService          100 Iniciando ações do serviço do executor
     129 Mar 17 13:41  Informação ActionsRunnerService          100 criar fonte de rastreamento de registro de evento para o serviço actions-runner

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 registro Runner_. Por exemplo:

[Fevb 12 12:37:07 INFO SelfUpdater] Uma atualização está disponível.

Além disso, você pode encontrar mais informações nos arquivos de registro SelfUpdate localizados no diretório _diag.

Resolução de problemas de contêineres em executores auto-hospedados

Verificar se o Docker está instalado

Se seus trabalhos exigirem contêineres, o executor auto-hospedado deverá ser baseado no Linux e deverá ter o Docker instalado. Verifique se o seu executor auto-hospedado tem o Docker instalado e se o serviço está em execução.

Você pode usar o systemctl para verificar o status do serviço:

$ sudo systemctl is-active docker.service
ativo

Se o Docker não estiver instalado, ações dependentes irão falhar com as seguintes mensagens de erro:

[2020-02-13 16:56:10Z INFO DockerCommandManager] Which: 'docker'
[2020-02-13 16:56:10Z INFO DockerCommandManager] Não encontrado.
[2020-02-13 16:56:10Z ERR  StepsRunner] Capturou exceção da etapa: System.IO.FileNotFoundException: Arquivo não encontrado: 'docker'

Verificar as permissões do Docker

Se seu trabalho falhar com o seguinte erro:

discar unix /var/run/docker.sock: conexão: permissão negada

Verifique se a conta de serviço do executor auto-hospedado tem permissão para usar o serviço do Docker. Você pode identificar esta conta verificando a configuração do executor auto-hospedado no systemd. Por exemplo:

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