Esta versión de GitHub Enterprise Server se discontinuó el 2024-09-25. No se realizarán lanzamientos de patch, ni siquiera para problemas de seguridad críticos. Para obtener rendimiento mejorado, seguridad mejorada y nuevas características, actualice a la versión más reciente de GitHub Enterprise Server. Para obtener ayuda con la actualización, póngase en contacto con el soporte técnico de GitHub Enterprise.

Ejecución de scripts antes o después de un trabajo

Los scripts se pueden ejecutar automáticamente en un ejecutor autohospedado, directamente antes o después de un trabajo.

En este artículo

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, consulta Desencadenamiento de los scripts a continuación.

Se admiten los siguientes lenguajes de scripting:

  • Bash: usa bash y puede recurrir a sh. Se ejecuta mediante la ejecución de -e {pathtofile}.
  • PowerShell: usa pwsh y puede recurrir a powershell. Se ejecuta mediante la ejecución de -command \". '{pathtofile}'\".

Escritura de los scripts

Los scripts personalizados pueden usar las características siguientes:

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, consulta 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.