Enterprise Server 3.15 est actuellement disponible en tant que version finale (RC).

Exécution de scripts avant ou après un travail

Les scripts peuvent s’exécuter automatiquement sur un exécuteur autohébergé, juste avant ou après un travail.

Dans cet article

À propos des scripts antérieurs et postérieurs aux travaux

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 d’événement webhook complète est disponible dans GITHUB_EVENT_PATH. Pour plus d’informations, consultez « Stocker des informations dans des variables ».
  • Commandes de workflow : les scripts peuvent utiliser des commandes de workflow. Pour plus d’informations, consultez « Workflow commands for GitHub Actions ». Les scripts peuvent également utiliser des fichiers d’environnement. Pour plus d’informations, consultez Fichiers d’environnement.

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 pour la console, car toute personne disposant d’un accès en lecture au dépôt peut voir la sortie dans les journaux d’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 afficher les résultats de vos scripts antérieurs aux travaux, vérifiez les journaux à la recherche d’entrées Set up runner. Pour plus d’informations sur l’examen des journaux, consultez « Using workflow run logs ».

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 d’exécuteur.

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). 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é à la fin du travail, avant la fin de ceci. 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 de workflow

Pour vérifier si vos scripts s’exécutent, vous pouvez passer en revue les journaux pour ce travail. 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 l’examen des journaux, consultez « Using workflow run logs ».