Supervisión y solución de problemas de ejecutores autohospedados

Uso de ejecutores autohospedados de nivel de repositorio

Es posible que no puedas crear un ejecutor autohospedado para un repositorio que es propiedad de la organización.

Los propietarios de empresa y de organización pueden elegir los repositorios que pueden crear ejecutores autohospedados en el nivel de repositorio. Los usuarios con el permiso "Administrar ejecutores de la organización y grupos de ejecutores" solo pueden elegir qué repositorios pueden crear ejecutores autohospedados de nivel de repositorio para repositorios de su organización.

Para obtener más información sobre los roles de organización personalizados, vea "Acerca de los roles personalizados de organización".

Para más información, consulta "Requerir políticas para las GitHub Actions en tu empresa" y "Inhabilitar o limitar GitHub Actions para tu organización".

Comprobar el estado de un servicio del ejecutor autoalojado

Un ejecutor autohospedado se puede ubicar en al repositorio, en la organización o en la configuración empresarial en GitHub Enterprise Server. Para administrar un ejecutor auto-hospedado, debes tener los siguientes permisos, dependiendo de donde se agregó éste:

• Repositorio de usuario: debe ser el propietario del repositorio.

• Organización: debe ser el propietario de una organización.

• Repositorio de la organización: debe ser el propietario de una organización o tener acceso de administrador al repositorio.

• Empresa: debe ser un administrador de sitio de GitHub Enterprise.

1. En el repositorio o la organización, vaya a la página principal y haga clic en Configuración.

2. En la barra lateral izquierda, haz clic en Acciones y, después, en Ejecutores.

3. En "Ejecutores", puedes ver una lista de los ejecutores registrados, incluyendo su nombre, etiquetas y estado.

   El estado puede ser uno de los siguientes:

   • Inactivo: el ejecutor está conectado a GitHub Enterprise Server y está listo para ejecutar trabajos.
   • Activo: el ejecutor ejecuta actualmente un trabajo.
   • Sin conexión: el ejecutor no está conectado a GitHub Enterprise Server. Esto puede deberse a que la máquina está fuera de línea, la aplicación del ejecutor autoalojado no se está ejecutando en la máquina o la aplicación del ejecutor autoalojado no se puede comunicar con GitHub Enterprise Server.

Solucionar problemas de la conectividad de red

Verificar la conectividad de red del ejecutor auto-hospedado

Puedes usar el script config de la aplicación de ejecutor autohospedado con el parámetro --check para comprobar que un ejecutor autohospedado puede acceder a todos los servicios de red necesarios en GitHub.

Además de --check, debe proporcionar dos argumentos al script:

• --url con la URL al repositorio, organización o empresa de GitHub. Por ejemplo, --url https://github.com/octo-org/octo-repo.
• --pat con el valor de un personal access token (classic), que debe tener el ámbito workflow o un fine-grained personal access token con acceso de lectura y escritura de flujos de trabajo. Por ejemplo, --pat ghp_abcd1234. Para obtener más información, vea «Administración de tokens de acceso personal».

Por ejemplo:

./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

El script prueba cada servicio y genera un valor PASSo FAIL para cada uno. Si tienes cualquier verificación fallida, puedes ver más detalles del problema en el archivo de bitácora de la verificación. Los archivos de registro se encuentra en el directorio _diag donde haya instalado la aplicación de ejecutor y la ruta del archivo de registro para cada comprobación se muestra en la salida de consola del script.

Si tienes alguna verificación fallida, también debes verificar que tu máquina ejecutora auto-hospedada cumpla con todos los requisitos de comunicación. Para obtener más información, vea «Acerca de los ejecutores autohospedados».

Inhabilitar la verificación de certificados TLS

De manera predeterminada, la aplicación de ejecutor autohospedado comprueba el certificado TLS para GitHub Enterprise Server. Si tu GitHub Enterprise Server tiene un certificado auto-firmado o emitido internamente, deberás inhabilitar la verificación de certificados TLS para propósitos de pruebas.

Para deshabilitar la comprobación de la certificación TLS en la aplicación de ejecutor autohospedado, establezca la variable de entorno GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY en 1 antes de configurar y ejecutar la aplicación de ejecutor autohospedado.

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 los archivos de bitácora de la aplicación del ejecutor auto-hospedado

Puedes supervisar el estado de la aplicación del ejecutor autohospedado y de sus actividades. Los archivos de registro se conservan en el directorio _diag donde ha instalado la aplicación de ejecutor y cada vez que se inicia la aplicación se genera un registro nuevo. El nombre de archivo comienza con Runner_, seguido de una marca de tiempo UTC de cuando se inició la aplicación.

Para obtener registros detallados sobre las ejecuciones de trabajos de flujo de trabajo, consulte la sección siguiente que describe los archivos Worker_.

Revisar el archivo de bitácora de un job

La aplicación del ejecutor auto-hospedado crea un archivo de bitácora detallado para cada job que procesa. Estos archivos se almacenan en el directorio _diag donde ha instalado la aplicación de ejecutor y el nombre de archivo comienza por 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

supervisar el proceso de actualización automática

Te recomendamos que revises el proceso de actualización automático a menudo, ya que el ejecutor auto-hospedado no podrá procesar jobs si cae debajo de cierto umbral de versiones. La aplicación del ejecutor auto-hospedado se actualiza automáticamente, pero nota que este proceso no incluye ninguna actualización al sistema operativo ni a otro tipo de software; necesitarás administrar estas actualizaciones por separado.

Puede ver las actividades de actualización en los archivos de registro Runner_. Por ejemplo:

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

Además, puede buscar más información en los archivos de registro SelfUpdate ubicados en el directorio _diag donde ha instalado la aplicación de ejecutor.

$ 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

Resolución de ejecutores sin conexión después de una actualización de GitHub Enterprise Server

Si usa ejecutores efímeros y ha deshabilitado las actualizaciones automáticas, antes de actualizar GitHub Enterprise Server debe actualizar los ejecutores autohospedados a la versión de la aplicación del ejecutor que ejecutará la instancia actualizada. La actualización de GitHub Enterprise Server antes de actualizar los ejecutores efímeros puede dar lugar a que los ejecutores se desconecten. Para obtener más información, vea «Información general del proceso de actualización».

Si los ejecutores están sin conexión por este motivo, actualízalos manualmente. Para obtener más información, consulta las instrucciones de instalación de la última versión en el repositorio actions/runner.

Comprobación del motor de Docker instalado en el ejecutor

Si se produce el error siguiente en la compilación:

Error: Input required and not supplied: java-version

Comprueba qué motor de Docker está instalado en el ejecutor autohospedado. Para pasar las entradas de una acción al contenedor de Docker, el ejecutor usa variables de entorno que podrían contener guiones como parte de sus nombres. Es posible que la acción no pueda obtener las entradas si el motor de Docker no es un ejecutable binario, sino un contenedor de shell o un vínculo (por ejemplo, un motor de Docker instalado en Linux mediante snap). Para solucionar este error, configura el ejecutor autohospedado de modo que use otro motor de Docker.

Para comprobar si el motor de Docker se instaló mediante snap, usa el comando which. En el ejemplo siguiente, el motor de Docker se instaló mediante snap:

$ which docker
/snap/bin/docker