Surveillance des exécuteurs auto-hébergés et résolution des problèmes

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.

1. Dans une organisation ou un référentiel, naviguez jusqu'à la page principale, puis cliquez sur Settings.

2. Dans la barre latérale gauche, cliquez sur Actions, puis sur Exécuteurs.

3. 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’étendue workflow, 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

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.

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_.

$ cat ~/actions-runner/.service
actions.runner.octo-org-octo-repo.runner01.service

$ 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)

sudo journalctl -u actions.runner.octo-org-octo-repo.runner01.service -f

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

% cat ~/actions-runner/.service
/Users/exampleUsername/Library/LaunchAgents/actions.runner.octo-org-octo-repo.runner01.plist

$ ./svc.sh status
status actions.runner.example.runner01:
/Users/exampleUsername/Library/LaunchAgents/actions.runner.example.runner01.plist
Started:
379 0 actions.runner.example.runner01

PS C:\actions-runner> Get-Content .service
actions.runner.octo-org-octo-repo.runner01.service

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

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.

$ sudo systemctl is-active docker.service
active

[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'

dial unix /var/run/docker.sock: connect: permission denied

$ 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