Acerca de los scripts previos y posteriores al trabajo
Puede ejecutar scripts de forma automática en un ejecutor autohospedado, ya sea antes de que se ejecute un trabajo o después de que un trabajo termine de ejecutarse. Puede usar estos scripts para admitir los requisitos del trabajo, como compilar o anular un entorno de ejecutor, o limpiar directorios. También puede usar estos scripts para realizar el seguimiento de la telemetría de uso de los ejecutores.
Los scripts personalizados se desencadenan automáticamente cuando se establece una variable de entorno específica en el ejecutor; la variable de entorno debe contener la ruta de acceso absoluta al script. Para más información, vea "Desencadenamiento de los scripts" a continuación.
Se admiten los siguientes lenguajes de scripting:
- Bash: usa
bash
y puede recurrir ash
. Se ejecuta mediante la ejecución de-e {pathtofile}
. - PowerShell: usa
pwsh
y puede recurrir apowershell
. Se ejecuta mediante la ejecución de-command \". '{pathtofile}'\"
.
Escritura de los scripts
Los scripts personalizados pueden usar las características siguientes:
- Variables: los scripts tienen acceso a las variables predeterminadas. La carga completa del evento de webhook se puede encontrar en
GITHUB_EVENT_PATH
. Para obtener más información, vea «Almacenamiento de información en variables». - Comandos de flujo de trabajo: los scripts pueden usar comandos de flujo de trabajo. Para obtener más información, consulta "Comandos de flujo de trabajo para Acciones de GitHub". Los scripts también pueden usar archivos de entorno. Para más información, vea Archivos de entorno.
Los archivos de script deben usar una extensión de archivo para el lenguaje pertinente, como .sh
o .ps1
, para poder ejecutarse correctamente.
Note
Evita usar los scripts para mostrar información confidencial en la consola, ya que cualquiera con acceso de lectura al repositorio podría ver la salida en los registros de la interfaz de usuario.
Control de códigos de salida
En el caso de los scripts previos al trabajo, el código de salida 0
indica que el script se ha completado correctamente y que el trabajo se ejecutará a continuación. Si hay otro código de salida, el trabajo no se ejecutará y se marcará como con error. Para ver los resultados de los scripts previos al trabajo, compruebe las entradas Set up runner
de los registros. Para obtener más información sobre la comprobación de los registros, consulta "Uso de registros de ejecución de flujo de trabajo".
Estos scripts no admiten la configuración continue-on-error
.
Desencadenamiento de los scripts
Los scripts personalizados deben estar ubicados en el ejecutor, pero no se deben almacenar en el directorio actions-runner
de la aplicación. Los scripts se ejecutan en el contexto de seguridad de la cuenta de servicio que ejecuta el servicio del ejecutor.
Note
Los scripts desencadenados se procesan de forma sincrónica, por lo que bloquearán la ejecución del trabajo mientras se ejecutan.
Los scripts se ejecutan de forma automática cuando el ejecutor tiene las siguientes variables de entorno que contienen una ruta de acceso absoluta al script:
ACTIONS_RUNNER_HOOK_JOB_STARTED
: el script definido en esta variable de entorno se desencadena cuando se ha asignado un trabajo a un ejecutor, pero antes de que el trabajo empiece a ejecutarse.ACTIONS_RUNNER_HOOK_JOB_COMPLETED
: el script definido en esta variable de entorno se activa al final del trabajo, después de que se hayan ejecutado todos los pasos definidos en el flujo de trabajo.
Para establecer estas variables de entorno, puede agregarlas al sistema operativo o a un archivo denominado .env
dentro del directorio de aplicaciones del ejecutor autohospedado (esto es, el directorio en el que descargó y desempaquetó el software del ejecutor). Por ejemplo, la siguiente entrada .env
hará que el ejecutor ejecute automáticamente un script, guardado como /opt/runner/cleanup_script.sh
en el equipó del ejecutor antes de que se ejecute cada trabajo:
ACTIONS_RUNNER_HOOK_JOB_STARTED=/opt/runner/cleanup_script.sh
Note
El script definido en ACTIONS_RUNNER_HOOK_JOB_COMPLETED
se ejecuta al final del trabajo, antes de que este se complete. Esto hace que no sea adecuado para los casos de uso que pueden interrumpir un ejecutor, como eliminar la máquina del ejecutor como parte de una implementación de escalado automático.
Solución de problemas
Permiso denegado
Si recibe un error de “permiso denegado” al intentar ejecutar un script, asegúrese de que el script sea ejecutable. Por ejemplo, en un terminal en Linux o macOS, puede usar el siguiente comando para convertir un archivo en ejecutable.
chmod +x PATH/TO/FILE
Para obtener información sobre el uso de flujos de trabajo para ejecutar scripts, consulte “Agregar scripts a tu flujo de trabajo”.
Sin configuración de tiempo de espera
Actualmente no hay ninguna configuración de tiempo de espera disponible para los scripts ejecutados por ACTIONS_RUNNER_HOOK_JOB_STARTED
o ACTIONS_RUNNER_HOOK_JOB_COMPLETED
. Como resultado, podría considerar la posibilidad de agregar el control de tiempo de espera al script.
Revisión del registro de ejecución del flujo de trabajo
Para confirmar si los scripts se están ejecutando, puede revisar los registros de ese trabajo. Los scripts se mostrarán en pasos independientes para Set up runner
o Complete runner
, en función de la variable de entorno que desencadene el script. Para obtener más información sobre la comprobación de los registros, consulta "Uso de registros de ejecución de flujo de trabajo".