Remarque : Les exécuteurs hébergés sur GitHub ne sont pas pris en charge sur GitHub Enterprise Server. Vous pouvez voir plus d’informations sur le support futur planifié dans la GitHub public roadmap.
Utilisation d’exécuteurs auto-hébergés au niveau du dépôt
Vous ne pourrez peut-être pas créer un exécuteur auto-hébergé pour un dépôt appartenant à une organisation.
Les propriétaires d’entreprise et d’organisation peuvent choisir les référentiels autorisés à créer des exécuteurs auto-hébergés au niveau du référentiel. .
Pour plus d’informations, consultez « Application de stratégies pour GitHub Actions dans votre entreprise » et « Désactivation ou limitation de la fonctionnalité GitHub Actions pour votre organisation ».
Vérification de l’état d’un exécuteur auto-hébergé
Un exécuteur auto-hébergé peut se trouver dans les paramètres du compte de votre dépôt, organisation ou les paramètres de votre entreprise sur GitHub Enterprise Server. Pour gérer un exécuteur auto-hébergé, vous devez disposer des autorisations suivantes, selon l'emplacement auquel il a été ajouté :
-
Dépôt utilisateur : Vous devez être le propriétaire du dépôt.
-
Organisation : Vous devez être propriétaire de l'organisation.
-
Dépôt d'organisation : Vous devez être propriétaire de l'organisation ou disposer d'un accès administrateur au dépôt.
-
Entreprise : Vous devez être administrateur de site GitHub Enterprise.
-
Dans votre organisation ou référentiel, accédez à la page principale et cliquez sur Paramètres.
-
Dans la barre latérale gauche, cliquez sur Actions, puis sur Exécuteurs.
-
Sous « Exécuteurs », vous pouvez consulter la liste des exécuteurs inscrits, y compris le nom, les étiquettes et le statut de l’exécuteur.
Il peut s’agir d’un des états suivants :
- Inactif : l’exécuteur est connecté à GitHub Enterprise Server et est prêt à exécuter des travaux.
- Actif : l’exécuteur exécute actuellement un travail.
- Hors connexion : l’exécuteur n’est pas connecté à GitHub Enterprise Server. Cela peut être dû au fait que la machine est hors connexion, que l’application d’exécuteur auto-hébergé n’est pas en cours d’exécution sur la machine ou que l’application d’exécuteur auto-hébergé ne peut pas communiquer avec GitHub Enterprise Server.
Résolution des problèmes de connectivité réseau
Vérification de la connectivité réseau d’un exécuteur auto-hébergé
Vous pouvez utiliser le script config
de l’application d’exécuteur auto-hébergé avec le paramètre --check
pour vérifier qu’un exécuteur auto-hébergé peut accéder à tous les services réseau requis sur GitHub.
En plus de --check
, vous devez fournir deux arguments au script :
--url
avec l’URL de votre dépôt, organisation ou entreprise GitHub. Par exemple :--url https://github.com/octo-org/octo-repo
.--pat
avec la valeur d’un personal access token (classic), qui doit avoir l’étendueworkflow
, ou un fine-grained personal access token avec accès en lecture et écriture aux workflows. Par exemple :--pat ghp_abcd1234
. Pour plus d’informations, consultez « Gestion de vos jetons d'accès personnels ».
Par exemple :
./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
Le script teste chaque service et génère une sortie PASS
ou FAIL
pour chacun d’eux. Si vous avez des vérifications ayant échoué, vous pouvez voir plus d’informations sur le problème dans le fichier journal concernant la vérification. Les fichiers journaux se trouvent dans le répertoire _diag
où vous avez installé l’application d’exécuteur, et le chemin d’accès du fichier journal pour chaque vérification s’affiche dans la sortie de console du script.
Si vous avez des vérifications ayant échoué, vous devez également vérifier que votre machine d’exécuteur auto-hébergé répond à toutes les exigences de communication. Pour plus d’informations, consultez « À propos des exécuteurs auto-hébergés ».
Désactivation de la vérification de certificat TLS
Par défaut, l’application d’exécuteur auto-hébergé vérifie le certificat TLS pour GitHub Enterprise Server. Si votre GitHub Enterprise Server possède un certificat auto-signé ou émis en interne, vous pouvez désactiver la vérification du certificat TLS à des fins de test.
Pour désactiver la vérification de la certification TLS dans l’application de l’exécuteur auto-hébergé, définissez la variable d’environnement GITHUB_ACTIONS_RUNNER_TLS_NO_VERIFY
sur 1
avant de configurer et d’exécuter l’application d’exécuteur auto-hébergé.
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
La désactivation de la vérification TLS n’est pas recommandée, car TLS assure la confidentialité et l’intégrité des données entre l’application d’exécuteur auto-hébergé et GitHub Enterprise Server. Nous vous recommandons d’installer le certificat GitHub Enterprise Server dans le magasin de certificats du système d’exploitation pour votre exécuteur auto-hébergé. Pour obtenir des conseils sur l’installation du certificat GitHub Enterprise Server, contactez votre fournisseur de système d’exploitation.
Examen des fichiers journaux d’application d’exécuteur auto-hébergé
Vous pouvez surveiller l’état de l’application d’exécuteur auto-hébergé et ses activités. Les fichiers journaux sont conservés dans le répertoire _diag
où vous avez installé l’application d’exécuteur, et un nouveau journal est généré chaque fois que l’application est démarrée. Le nom de fichier commence par Runner_
et est suivi d’un horodateur UTC indiquant l’heure de démarrage de l’application.
Warning
Les fichiers journaux des applications d’exécuteurs pour les exécuteurs éphémères doivent être transmis et conservés en externe à des fins de dépannage et de diagnostic. Pour plus d’informations sur les exécuteurs éphémères et la mise à l’échelle automatique des exécuteurs auto-hébergés, consultez « Mise à l’échelle automatique avec des exécuteurs auto-hébergés ».
Pour obtenir des journaux détaillés sur les exécutions de tâches de workflow, consultez la section suivante décrivant les fichiers Worker_
.
Examen du fichier journal d’un travail
L’application d’exécuteur auto-hébergé crée un fichier journal détaillé pour chaque travail qu’elle traite. Ces fichiers sont stockés dans le répertoire _diag
où vous avez installé l’application d’exécuteur, et le nom de fichier commence par Worker_
.
Utilisation de journalctl pour vérifier le service d’application d’exécuteur auto-hébergé
Pour les exécuteurs auto-hébergés basés sur Linux qui exécutent l’application à l’aide d’un service, vous pouvez utiliser journalctl
pour surveiller leur activité en temps réel. Le service basé sur systemd par défaut utilise la convention d’affectation de noms suivante : actions.runner.<org>-<repo>.<runnerName>.service
. Ce nom est tronqué s’il dépasse 80 caractères. Par conséquent, la meilleure façon de trouver le nom du service est de vérifier le fichier .service. Par exemple :
$ cat ~/actions-runner/.service
actions.runner.octo-org-octo-repo.runner01.service
Si cela échoue du fait que le service est installé ailleurs, vous pouvez rechercher le nom du service dans la liste des services en cours d’exécution. Par exemple, sur la plupart des systèmes Linux, vous pouvez utiliser la commande 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)
Vous pouvez utiliser journalctl
pour surveiller l’activité en temps réel de l’exécuteur auto-hébergé :
sudo journalctl -u actions.runner.octo-org-octo-repo.runner01.service -f
Dans cet exemple de sortie, vous pouvez voir runner01
démarrer, recevoir un travail nommé testAction
, puis afficher l’état résultant :
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
Pour afficher la configuration systemd
, vous pouvez localiser le fichier de service ici : /etc/systemd/system/actions.runner.<org>-<repo>.<runnerName>.service
.
Si vous souhaitez personnaliser le service d’application d’exécuteur auto-hébergé, ne modifiez pas directement ce fichier. Suivez les instructions décrites dans « Configuration de l’application d’exécuteur auto-hébergé en tant que service ».
Utilisation de launchd
pour vérifier le service de l’application d’exécuteur auto-hébergé
Pour les exécuteurs auto-hébergés basés sur macOS qui exécutent l’application en tant que service, vous pouvez utiliser launchctl
pour surveiller leur activité en temps réel. Le service par défaut basé sur launchd utilise la convention d’affectation de noms suivante : actions.runner.<org>-<repo>.<runnerName>
. Ce nom est tronqué s’il dépasse 80 caractères, de sorte que la meilleure façon de rechercher le nom du service consiste à vérifier le fichier .service dans le répertoire de l’exécuteur :
% cat ~/actions-runner/.service
/Users/exampleUsername/Library/LaunchAgents/actions.runner.octo-org-octo-repo.runner01.plist
Le script svc.sh
utilise launchctl
pour vérifier si l’application est en cours d’exécution. Par exemple :
$ ./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 sortie obtenue inclut l’ID de processus et le nom du service launchd
de l’application.
Pour afficher la configuration launchd
, vous pouvez localiser le fichier de service ici : /Users/exampleUsername/Library/LaunchAgents/actions.runner.<repoName>.<runnerName>.service
.
Si vous souhaitez personnaliser le service d’application d’exécuteur auto-hébergé, ne modifiez pas directement ce fichier. Suivez les instructions décrites dans « Configuration de l’application d’exécuteur auto-hébergé en tant que service ».
Utilisation de PowerShell pour vérifier le service de l’application d’exécuteur auto-hébergé
Pour les exécuteurs auto-hébergés basés sur Windows qui exécutent l’application en tant que service, vous pouvez utiliser PowerShell pour surveiller leur activité en temps réel. Le service utilise la convention d’affectation de noms GitHub Actions Runner (<org>-<repo>.<runnerName>)
. Vous pouvez également rechercher le nom du service en vérifiant le fichier .service dans le répertoire de l’exécuteur :
PS C:\actions-runner> Get-Content .service
actions.runner.octo-org-octo-repo.runner01.service
Vous pouvez afficher l’état de l’exécuteur dans l’application Windows Services (services.msc
). Vous pouvez également utiliser PowerShell pour vérifier si le service est en cours d’exécution :
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
Vous pouvez utiliser PowerShell pour vérifier l’activité récente de l’exécuteur auto-hébergé. Dans cet exemple de sortie, vous pouvez voir le démarrage de l’application, recevoir un travail nommé testAction
, puis afficher l’état résultant :
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
Surveillance du processus de mise à jour automatique
Nous vous recommandons de vérifier régulièrement le processus de mise à jour automatique, car l’exécuteur auto-hébergé ne pourra pas traiter les travaux s’il tombe en dessous d’un certain seuil de version. L’application d’exécuteur auto-hébergé est automatiquement mise à jour, mais notez que ce processus n’inclut aucune mise à jour du système d’exploitation ni d’autres logiciels. Vous devez gérer séparément ces mises à jour.
Vous pouvez consulter les activités de mise à jour dans les fichiers journaux Runner_
. Par exemple :
[Feb 12 12:37:07 INFO SelfUpdater] An update is available.
En outre, vous trouverez plus d’informations dans les fichiers journaux SelfUpdate situés dans le répertoire _diag
où vous avez installé l’application d’exécuteur.
Résolution des problèmes liés aux conteneurs dans les exécuteurs auto-hébergés
Vérification de l’installation de Docker
Si vos travaux nécessitent des conteneurs, l’exécuteur auto-hébergé doit être basé sur Linux et Docker doit être installé. Vérifiez que votre exécuteur auto-hébergé dispose de Docker et que le service est en cours d’exécution.
Vous pouvez utiliser systemctl
pour vérifier l’état du service :
$ sudo systemctl is-active docker.service
active
Si Docker n’est pas installé, les actions dépendantes échouent avec les erreurs suivantes :
[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'
Vérification des autorisations Docker
Si votre travail échoue avec l’erreur suivante :
dial unix /var/run/docker.sock: connect: permission denied
Vérifiez que le compte de service de l’exécuteur auto-hébergé dispose de l’autorisation nécessaire pour utiliser le service Docker. Vous pouvez identifier ce compte en vérifiant la configuration de l’exécuteur auto-hébergé dans systemd
. Par exemple :
$ sudo systemctl show -p User actions.runner.octo-org-octo-repo.runner01.service
User=runner-user
Résolution des exécuteurs hors connexion après une mise à niveau de GitHub Enterprise Server
Si vous utilisez des exécuteurs éphémères et que vous avez désactivé les mises à jour automatiques, avant de mettre à niveau GitHub Enterprise Server, vous devez d’abord mettre à niveau vos exécuteurs auto-hébergés vers la version de l’application de l’exécuteur que votre instance mise à niveau exécutera. La mise à niveau de GitHub Enterprise Server avant de mettre à niveau des exécuteurs éphémères peut entraîner le passage hors connexion de vos exécuteurs. Pour plus d’informations, consultez « Vue d'ensemble du processus de mise à niveau ».
Si vos exécuteurs sont hors connexion pour cette raison, mettez à jour manuellement les exécuteurs. Pour plus d’informations, consultez les instructions d’installation pour la dernière version dans le dépôt actions/runner.
Vérification du moteur Docker installé sur l’exécuteur
Si votre build échoue avec l’erreur suivante :
Error: Input required and not supplied: java-version
Vérifiez quel moteur Docker est installé sur votre exécuteur auto-hébergé. Pour passer les entrées d’une action dans le conteneur Docker, l’exécuteur utilise des variables d’environnement dont le nom est susceptible de contenir des tirets. L’action peut ne pas être en mesure d'obtenir les entrées si le moteur Docker n’est pas un exécutable binaire, mais plutôt un wrapper d’interpréteur de commandes ou un lien (par exemple un moteur Docker installé sur Linux à l’aide de snap
). Pour résoudre cette erreur, configurez votre exécuteur auto-hébergé de façon à utiliser un autre moteur Docker.
Pour vérifier si votre moteur Docker a été installé à l’aide de snap
, utilisez la commande which
. Dans l’exemple suivant, le moteur Docker a été installé à l’aide de snap
:
$ which docker
/snap/bin/docker