À propos des scripts de pré-travail et de post-travail
Vous pouvez exécuter automatiquement des scripts sur un exécuteur auto-hébergé, soit avant l’exécution d’un travail, soit après son exécution. Vous pouvez utiliser ces scripts pour prendre en charge les exigences du travail, telles que la création ou la suppression d’un environnement d’exécuteur ou le nettoyage des répertoires. Vous pouvez également utiliser ces scripts pour suivre les données de télémétrie de la façon dont vos exécuteurs sont utilisés.
Les scripts personnalisés sont automatiquement déclenchés lorsqu’une variable d’environnement spécifique est définie sur l’exécuteur. La variable d’environnement doit contenir le chemin absolu vers le script. Pour plus d’informations, consultez « Déclenchement des scripts » ci-dessous.
Les langages de script suivants sont pris en charge :
-
**Bash** : utilise `bash` et peut basculer vers `sh`. S’exécute en exécutant `-e {pathtofile}`. -
**PowerShell** : utilise `pwsh` et peut basculer vers `powershell`. S’exécute en exécutant `-command \". '{pathtofile}'\"`.
Écriture des scripts
Vos scripts personnalisés peuvent utiliser les fonctionnalités suivantes :
-
**Variables** : Les scripts ont accès aux variables par défaut. La charge utile complète de l’événement webhook est disponible dans `GITHUB_EVENT_PATH`. Pour plus d’informations, consultez « [AUTOTITLE](/actions/reference/variables-reference#default-environment-variables) ». -
**Commandes de workflow** : les scripts peuvent utiliser des commandes de workflow. Pour plus d’informations, consultez « [AUTOTITLE](/actions/using-workflows/workflow-commands-for-github-actions) ». Les scripts peuvent également utiliser des fichiers d’environnement. Pour plus d’informations, consultez [Fichiers d’environnement](/actions/using-workflows/workflow-commands-for-github-actions#environment-files).
Vos fichiers de script doivent utiliser une extension de fichier pour le langage approprié, comme .sh ou .ps1, afin de s’exécuter correctement.
Remarque
Évitez d'utiliser vos scripts pour générer des informations sensibles vers la console, car toute personne disposant d'un accès en lecture au référentiel peut voir le résultat dans les journaux de l'interface utilisateur.
Gestion des codes de sortie
Pour les scripts antérieurs aux travaux, le code de sortie 0 indique que le script s’est terminé correctement et que le travail va ensuite s’exécuter. S’il existe un autre code de sortie, le travail ne sera pas exécuté et sera marqué comme ayant échoué. Pour consulter les résultats de vos scripts exécutés avant les tâches, vérifiez les journaux pour y trouver des entrées Set up runner. Pour plus d’informations sur la consultation des journaux, consultez « Utilisation des journaux d’exécution de flux de travail ».
Le paramètre continue-on-error n’est pas pris en charge pour une utilisation par ces scripts.
Déclenchement des scripts
Les scripts personnalisés doivent se trouver sur l’exécuteur, mais ne doivent pas être stockés dans le répertoire de l’application actions-runner. Les scripts sont exécutés dans le contexte de sécurité du compte de service qui exécute le service runner.
Remarque
Les scripts déclenchés sont traités de manière synchrone, de manière à bloquer l’exécution des travaux pendant leur exécution.
Les scripts sont exécutés automatiquement lorsque l’exécuteur possède les variables d’environnement suivantes contenant un chemin absolu vers le script :
*
ACTIONS_RUNNER_HOOK_JOB_STARTED : le script défini dans cette variable d’environnement est déclenché quand un travail a été affecté à un exécuteur, mais avant l’exécution du travail.
*
ACTIONS_RUNNER_HOOK_JOB_COMPLETED : le script défini dans cette variable d’environnement est déclenché à la fin du travail, après l’exécution de toutes les étapes définies dans le flux de travail.
Pour définir ces variables d’environnement, vous pouvez les ajouter au système d’exploitation ou à un fichier nommé .env dans le répertoire d’application d’exécuteur auto-hébergé (c'est-à-dire le répertoire dans lequel vous avez téléchargé et décompressé le logiciel d’exécuteur). Notez que toute modification apportée au fichier .env nécessite le redémarrage de l’exécuteur.
Par exemple, l'entrée suivante .env permet à l’exécuteur d'exécuter automatiquement un script, sauvegardé sur l’ordinateur d’exécuteur /opt/runner/cleanup_script.sh, avant l'exécution de chaque projet :
ACTIONS_RUNNER_HOOK_JOB_STARTED=/opt/runner/cleanup_script.sh
Remarque
Le script défini dans ACTIONS_RUNNER_HOOK_JOB_COMPLETED est exécuté avant la complétion du travail, avant qu'il ne soit terminé. Cela rend inadapté aux cas d’usage susceptibles d’interrompre un exécuteur, par exemple la suppression de l’ordinateur de l’exécuteur dans le cadre d’une implémentation de mise à l’échelle automatique.
Dépannage
Autorisation refusée
Si vous obtenez une erreur « autorisation refusée » lorsque vous tentez d'exécuter un script, assurez-vous que le script est exécutable. Par exemple, dans un terminal sous Linux ou macOS, vous pouvez utiliser la commande suivante pour rendre un fichier exécutable.
chmod +x PATH/TO/FILE
Pour en savoir plus sur l'utilisation des flux de travail pour exécuter des scripts, consultez « Ajout de scripts à votre workflow ».
Pas de paramètre de délai d’attente
Il n’existe actuellement aucun paramètre de délai d’attente disponible pour les scripts exécutés par ACTIONS_RUNNER_HOOK_JOB_STARTED ou ACTIONS_RUNNER_HOOK_JOB_COMPLETED. Par conséquent, vous pouvez envisager d’ajouter la gestion des délais d’expiration à votre script.
Examen du journal d’exécution du workflow
Pour vérifier si vos scripts s'exécutent, vous pouvez consulter les journaux pour cette tâche. Les scripts sont répertoriés dans des étapes distinctes pour Set up runner ou Complete runner, selon la variable d’environnement qui déclenche le script. Pour plus d’informations sur la consultation des journaux, consultez « Utilisation des journaux d’exécution de flux de travail ».