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 la organización pueden elegir los repositorios que pueden crear ejecutores autohospedados en el nivel de repositorio. .
Para más información, consulta "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 de cuenta empresarial en GitHub. 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.
-
En el repositorio o la organización, ve a la página principal y haz clic en Settings.
-
En la barra lateral izquierda, haz clic en Acciones y, después, en Ejecutores.
-
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 y está listo para ejecutar trabajos.
- Activo: el ejecutor ejecuta actualmente un trabajo.
- Sin conexión: el ejecutor no está conectado a GitHub. 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.
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 ámbitoworkflow
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 PASS
o 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. Si encuentras problemas de red, 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
Warning
No se recomienda inhabilitar la comprobación TLS, ya que TLS proporciona privacidad e integridad de datos entre la aplicación de ejecutor autohospedado y GitHub. Te recomendamos instalar el certificado GitHub en el almacén de certificados del sistema operativo para tu ejecutor auto-hospedado. Para encontrar instrucciones sobre cómo instalar el certificado GitHub, verifícalo con el proveedor del sistema operativo.
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.
Warning
Los archivos de registro de aplicaciones del ejecutor para ejecutores efímeros deben reenviarse y conservarse externamente para solucionar problemas y realizar diagnósticos. Para obtener más información sobre los ejecutores efímeros y los autohospedadosde escalado automático, consulte "Autoescalar con ejecutores auto-hospedados".
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_
.
Utilizar journalctl para revisar el servicio de la aplicación del ejecutor auto-hospedado
Para los ejecutores autohospedados basados en Linux que ejecutan la aplicación mediante un servicio, puede usar journalctl
a fin de supervisar su actividad en tiempo real. El servicio predeterminado basado en systemd usa la siguiente convención de nomenclatura: actions.runner.<org>-<repo>.<runnerName>.service
. Este nombre se trunca si supera los 80 caracteres, por lo que la manera preferida de buscar el nombre del servicio consiste en comprobar el archivo .service. Por ejemplo:
$ cat ~/actions-runner/.service
actions.runner.octo-org-octo-repo.runner01.service
Si esto falla debido a que el servicio se instaló en alguna otra parte, puedes encontrar el nombre del servicio en la lista de servicios en ejecución. Por ejemplo, en la mayoría de los sistemas Linux, puede usar el comando systemctl
:
$ 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)
Puedes usar journalctl
para supervisar la actividad en tiempo real del ejecutor autohospedado:
sudo journalctl -u actions.runner.octo-org-octo-repo.runner01.service -f
En esta salida de ejemplo, puede ver que se inicia runner01
, se recibe un trabajo denominado testAction
y, después, se muestra el estado resultante:
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
Para ver la configuración de systemd
, puede encontrar el archivo de servicio aquí: /etc/systemd/system/actions.runner.<org>-<repo>.<runnerName>.service
.
Si quieres personalizar el servicio de la aplicación del ejecutor auto-hospedado, no modifiques directamente este archivo. Sigue las instrucciones descritas en "Configurar la aplicación del ejecutor autoalojado como un servicio".
Uso de launchd
para comprobar el servicio de la aplicación de ejecutor autohospedado
Para los ejecutores autohospedados basados en macOS que ejecutan la aplicación como un servicio, puedes usar launchctl
a fin de supervisar su actividad en tiempo real. El servicio predeterminado basado en launchd usa la siguiente convención de nomenclatura: actions.runner.<org>-<repo>.<runnerName>
. Este nombre se trunca si supera los 80 caracteres, por lo que la manera preferida de buscar el nombre del servicio consiste en comprobar el archivo .service en el directorio del ejecutor:
% cat ~/actions-runner/.service
/Users/exampleUsername/Library/LaunchAgents/actions.runner.octo-org-octo-repo.runner01.plist
El script svc.sh
usa launchctl
para comprobar si la aplicación está en ejecución. Por ejemplo:
$ ./svc.sh status
status actions.runner.example.runner01:
/Users/exampleUsername/Library/LaunchAgents/actions.runner.example.runner01.plist
Started:
379 0 actions.runner.example.runner01
La salida generada incluye el id. del proceso y el nombre del servicio launchd
de la aplicación.
Para ver la configuración de launchd
, puede encontrar el archivo de servicio aquí: /Users/exampleUsername/Library/LaunchAgents/actions.runner.<repoName>.<runnerName>.service
.
Si quieres personalizar el servicio de la aplicación del ejecutor auto-hospedado, no modifiques directamente este archivo. Sigue las instrucciones descritas en "Configurar la aplicación del ejecutor autoalojado como un servicio".
Utilizar PowerShell para revisar el servicio de la aplicación del ejecutor auto-hospedado
Para los ejecutores autohospedados basados en Windows que se ejecuten en la aplicación como servicio, puedes utilizar PowerShell para supervisar su actividad en tiempo real. El servicio usa la convención de nomenclatura GitHub Actions Runner (<org>-<repo>.<runnerName>)
. También puede buscar el nombre del servicio si consulta el archivo .service en el directorio del ejecutor:
PS C:\actions-runner> Get-Content .service
actions.runner.octo-org-octo-repo.runner01.service
Puede ver el estado del ejecutor en la aplicación Servicios de Windows (services.msc
). También puedes utilizar PowerShell para revisar si el servicio se está ejecutando:
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
Puedes utilizar PowerShell para revisar la actividad reciente del ejecutor auto-hospedado. En esta salida de ejemplo, puede ver que se inicia la aplicación, se recibe un trabajo denominado testAction
y, después, se muestra el estado resultante:
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.
Solucionar problemas en los contenedores de los ejecutores auto-hospedados
Revisar que se haya instalado Docker
Si tus jobs necesitan contenedores, entonces el ejecutor auto-hospedado debe estar basado en Linux y necesita contar con Docker instalado. Revisa que tu ejecutor auto-hospedado tenga Docker instalado y que el servicio se esté ejecutando.
Puede usar systemctl
para comprobar el estado del servicio:
$ sudo systemctl is-active docker.service
active
Si no se ha instalado Docker, entonces las acciones dependientes fallarán con los siguientes errores:
[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'
Revisar los permisos de Docker
Si tu job falla con el siguiente error:
dial unix /var/run/docker.sock: connect: permission denied
Revisa que la cuenta de servicio del ejecutor auto-hospedado tenga permiso de utilizar el servicio de Docker. Puede identificar esta cuenta si comprueba la configuración del ejecutor autohospedado en systemd
. Por ejemplo:
$ sudo systemctl show -p User actions.runner.octo-org-octo-repo.runner01.service
User=runner-user
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