Résolution des problèmes liés à GitHub Actions pour votre entreprise

Vérification de l’intégrité de GitHub Actions

Vous pouvez vérifier l’intégrité de GitHub Actions sur votre instance GitHub Enterprise Server avec l’utilitaire en ligne de commande ghe-actions-check. Pour plus d’informations, consultez « Utilitaires de ligne de commande » et « Accès à l’interpréteur de commandes d’administration (SSH) ».

Configuration d’exécuteurs auto-hébergés lors de l’utilisation d’un certificat auto-signé pour GitHub Enterprise Server

Nous vous recommandons vivement de configurer TLS sur GitHub Enterprise Server avec un certificat signé par une autorité de confiance. Bien qu’un certificat autosigné puisse fonctionner, une configuration supplémentaire est nécessaire pour vos exécuteurs autohébergés. Elle n’est pas recommandée pour les environnements de production. Pour plus d’informations, consultez « Configuration de TLS ».

Installation du certificat sur l’ordinateur exécuteur

Pour qu’un exécuteur auto-hébergé se connecte à une instance GitHub Enterprise Server en utilisant un certificat auto-signé, vous devez installer le certificat sur l’ordinateur exécuteur afin de renforcer la sécurité de la connexion.

Pour savoir comment installer un certificat, consultez la documentation du système d’exploitation de votre exécuteur.

Configuration de Node.JS pour utiliser le certificat

La plupart des actions sont écrites en JavaScript et exécutées avec Node.js, qui n’utilise pas le magasin de certificats du système d’exploitation. Pour que l’application d’exécuteur auto-hébergé utilise le certificat, vous devez définir la variable d’environnement NODE_EXTRA_CA_CERTS sur l’ordinateur exécuteur.

Vous pouvez définir la variable d'environnement comme une variable d'environnement système ou la déclarer dans un fichier appelé .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 de l’exécuteur).

Par exemple :

NODE_EXTRA_CA_CERTS=/usr/share/ca-certificates/extra/mycertfile.crt

Les variables d’environnement étant lues au démarrage de l’application d’exécuteur auto-hébergé, vous devez définir les variables d’environnement avant de configurer ou de démarrer l’application d’exécuteur auto-hébergé. Si la configuration de votre certificat change, vous devez redémarrer l’application d’exécuteur auto-hébergé.

Configuration de conteneurs Docker pour utiliser le certificat

Si vous utilisez des actions de conteneur ou des conteneurs de service Docker dans vos workflows, vous devrez peut-être aussi installer le certificat dans votre image Docker en plus de définir la variable d’environnement ci-dessus.

Configuration des paramètres de proxy HTTP pour GitHub Actions

Si vous avez un serveur proxy HTTP configuré sur GitHub :

Vous devez ajouter .localhost, 127.0.0.1 et ::1 à la liste d’Exclusion du proxy HTTP (dans cet ordre).
Si votre emplacement de stockage externe n’est pas routable, vous devez également ajouter l’URL de votre stockage externe à la liste d’exclusion.

Pour plus d’informations sur la modification de vos paramètres de proxy, consultez « Configuration d’un serveur proxy web de trafic sortant ».

Si ces paramètres ne sont pas correctement configurés, vous obtiendrez peut-être des erreurs telles que Resource unexpectedly moved to https://IP-ADDRESS pendant la définition ou la modification de votre configuration GitHub Actions.

Exécuteurs ne se connectant pas à GitHub Enterprise Server avec un nouveau nom d’hôte

Avertissement : ne modifiez pas le nom d’hôte de GitHub Enterprise Server après la configuration initiale. La modification du nom d’hôte entraînera un comportement inattendu, pouvant aller jusqu’à des interruptions de l’instance et l’invalidation des clés de sécurité des utilisateurs. Si vous avez modifié le nom d’hôte de votre instance et rencontrez des problèmes, contactez Support GitHub Enterprise ou Support Premium GitHub.

Si vous déployez GitHub Enterprise Server dans votre environnement avec un nouveau nom d’hôte et que l’ancien nom d’hôte ne se résout plus en votre instance, les exécuteurs auto-hébergés ne pourront pas se connecter à l’ancien nom d’hôte et n’exécuteront aucun travail.

Vous devrez mettre à jour la configuration de vos exécuteurs auto-hébergés pour qu’ils utilisent le nouveau nom d’hôte de votre instance GitHub Enterprise Server. Pour chaque exécuteur auto-hébergé, vous devrez effectuer l’une des procédures suivantes :

Dans le répertoire de l’application d’exécuteur auto-hébergé, modifiez les fichiers .runner et .credentials pour remplacer toutes les occurrence de l’ancien nom d’hôte par le nouveau nom d’hôte, puis redémarrez l’application d’exécuteur auto-hébergé.
Supprimez l’exécuteur de GitHub Enterprise Server à l’aide de l’interface utilisateur, puis rajoutez-le. Pour plus d’informations, consultez « Suppression d’exécuteurs auto-hébergés » et « Ajout d’exécuteurs auto-hébergés ».

Travaux bloqués et limites de mémoire et de processeur GitHub Actions

GitHub Actions se compose de plusieurs services s’exécutant sur votre instance GitHub Enterprise Server. Par défaut, ces services sont configurés avec des limites de processeur et de mémoire par défaut qui sont censées fonctionner avec la plupart des instances. Cependant, les utilisateurs qui sollicitent fortement GitHub Actions peuvent avoir besoin d’ajuster ces paramètres.

Si vous remarquez que les travaux ne se lancent pas (même en présence d’exécuteurs inactifs) ou que leur progression n’est pas mise à jour ou qu’elle ne varie pas dans l’interface utilisateur, il se peut que vous avez atteint les limites de processeur ou de mémoire.

1. Vérifier l’utilisation globale du processeur et de la mémoire dans la console de gestion

Accédez à la console de gestion puis, dans le tableau de bord moniteur, sous « Intégrité du système », inspectez les graphiques globaux du processeur et de la mémoire. Pour plus d’informations, consultez « Accès au tableau de bord moniteur ».

Si l’utilisation globale du processeur sous « Intégrité du système » est proche de 100 % ou qu’il ne reste plus de mémoire libre, votre instance GitHub Enterprise Server s’exécute au maximum de sa capacité et doit faire l’objet d’un scale-up. Pour plus d’informations, consultez « Augmentation des ressources processeur ou mémoire ».

2. Vérifier l’utilisation globale du processeur et de la mémoire pour les travaux Nomad dans la console de gestion

Si l’utilisation globale du processeur et de la mémoire sous « Intégrité du système » est correcte, faites défiler la page du tableau de bord moniteur vers le bas jusqu’à la section « Travaux Nomad », puis examinez les graphiques « Pourcentage processeur » et « Utilisation de la mémoire ».

Chaque tracé visible dans ces graphiques correspond à un service. Pour les services GitHub Actions, recherchez :

mps_frontend
mps_backend
token_frontend
token_backend
actions_frontend
actions_backend

Si l’un de ces services a atteint un taux d’utilisation du processeur de 100 % ou en est proche ou que la mémoire est proche de leur limite (2 Go par défaut), il est peut-être nécessaire d’augmenter les ressources allouées à ces services. Parmi les services ci-dessus, notez ceux qui sont proches de leur limite ou qui l’ont atteinte.

3. Augmenter l’allocation de ressources pour les services ayant atteint leur limite

Connectez-vous à l’interpréteur de commandes d’administration avec SSH. Pour plus d’informations, consultez « Accès à l’interpréteur de commandes d’administration (SSH) ».
Exécutez la commande suivante pour voir quelles ressources sont disponibles pour une allocation :
```
nomad node status -self
```
Dans la sortie, recherchez la section « Allocated Resources » (Ressources allouées). Il se présente sous la forme suivante :
```
Allocated Resources
CPU              Memory          Disk
7740/49600 MHZ   23 GiB/32 GiB   4.4 GiB/7.9 GiB
```
Pour le processeur et la mémoire, la quantité totale allouée pour tous les services correspond à la valeur de gauche, et la quantité disponible correspond à la valeur de droite. Dans l’exemple ci-dessus, la quantité de mémoire allouée est de 23 Gio sur un total de 32 Gio. Cela signifie qu’il reste 9 Gio de mémoire à allouer.

Warning

Veillez à ne pas allouer plus de ressources que vous n’en possédez au total, car les services ne démarreront pas.
Passez au répertoire /etc/consul-templates/etc/nomad-jobs/actions :
```
cd /etc/consul-templates/etc/nomad-jobs/actions
```
Ce répertoire contient trois fichiers qui correspondent aux services GitHub Actions ci-dessus :
- mps.hcl.ctmpl
- token.hcl.ctmpl
- actions.hcl.ctmpl
Pour les services dont vous avez noté qu’ils nécessitent un ajustement, ouvrez le fichier correspondant et recherchez le groupe resources qui se présente comme suit :
```
resources {
  cpu = 512
  memory = 2048
  network {
    port "http" { }
  }
}
```
Les valeurs sont exprimées en MHz pour les ressources processeur et en Mo pour les ressources mémoire.

Ainsi, pour augmenter les limites des ressources dans l’exemple ci-dessus, avec 1 GHz pour le processeur et 4 Go pour la mémoire, apportez les modifications suivantes :
```
resources {
  cpu = 1024
  memory = 4096
  network {
    port "http" { }
  }
}
```
Enregistrez et fermez le fichier.
Exécutez ghe-config-apply pour appliquer les modifications.

Pendant l’exécution de ghe-config-apply, si vous obtenez la sortie Failed to run nomad job '/etc/nomad-jobs/<name>.hcl', il est probable que la modification a occasionné une surallocation de ressources processeur ou mémoire. Dans ce cas, modifiez à nouveau les fichiers de configuration et réduisez la quantité de ressources processeur et mémoire allouées, puis réexécutez ghe-config-apply.
Une fois la configuration appliquée, exécutez ghe-actions-check pour vérifier que les services GitHub Actions sont opérationnels.

Résolution des défaillances quand Dependabot déclenche des workflows existants

Après avoir configuré les mises à jour Dependabot pour votre instance GitHub Enterprise Server, il se peut que constatiez des défaillances quand des workflows existants sont déclenchés par des événements Dependabot.

Par défaut, les exécutions de workflows GitHub Actions qui sont déclenchées par Dependabot à partir d’événements push, pull_request, pull_request_review ou pull_request_review_comment ont considérées comme ayant été ouvertes à partir d’une duplication (fork) de dépôt. Contrairement aux workflows déclenchés par d’autres acteurs, cela signifie qu’ils reçoivent un GITHUB_TOKEN en lecture seule et qu’ils n’ont pas accès aux secrets qui sont normalement disponibles. Ainsi, les flux de travail qui tentent d’écrire dans le dépôt échouent quand ils sont déclenchés par Dependabot.

Il existe trois façons de résoudre ce problème :

Vous pouvez mettre à jour vos workflows de sorte qu’ils ne soient plus déclenchés par Dependabot en utilisant une expression de ce type : if: github.actor != 'dependabot[bot]'. Pour plus d’informations, consultez « Évaluer les expressions dans les workflows et les actions ».
Vous pouvez modifier vos workflows de sorte qu’ils utilisent un processus en deux étapes qui comprend pull_request_target qui ne présente pas ces limites. Pour plus d’informations, consultez « Automatisation de Dependabot avec GitHub Actions ».
Vous pouvez permettre aux workflows déclenchés par Dependabot d’accéder aux secrets et autoriser le terme permissions à augmenter l’étendue par défaut de GITHUB_TOKEN. Pour plus d’informations, consultez « Permettre aux workflows déclenchés par Dependabot d’accéder aux secrets et leur accorder des autorisations supérieures » ci-dessous.

Permettre aux workflows déclenchés par Dependabot d’accéder aux secrets et leur accorder des autorisations supérieures

Connectez-vous à l’interpréteur de commandes d’administration avec SSH. Pour plus d’informations, consultez « Accès à l’interpréteur de commandes d’administration (SSH) ».
Pour supprimer les limites sur les workflows déclenchés par Dependabot sur votre instance GitHub Enterprise Server, utilisez la commande suivante.
```
ghe-config app.actions.disable-dependabot-enforcement true
```
Appliquez la configuration.
```
ghe-config-apply
```
Revenez à GitHub Enterprise Server.

Résolution des problèmes liés aux actions groupées dans GitHub Actions

Si vous recevez l’erreur suivante lors de l’installation de GitHub Actions dans GitHub Enterprise Server, vous pouvez résoudre le problème en installant les actions groupées et les modèles de workflow officiels.

A part of the Actions setup had problems and needs an administrator to resolve.

Pour installer les actions groupées et les modèles de workflow officiels au sein d’une organisation désignée dans GitHub Enterprise Server, suivez cette procédure.

Identifiez une organisation qui stockera les actions groupées et les modèles de workflow officiels. Vous pouvez créer une nouvelle organisation ou en réutiliser une existante.
- Pour créer une organisation, consultez « Création d’une organisation à partir de zéro ».
- Pour obtenir de l’aide concernant le nom à donner à l’organisation, consultez « Bien démarrer avec GitHub Actions pour GitHub Enterprise Server ».
Connectez-vous à l’interpréteur de commandes d’administration avec SSH. Pour plus d’informations, consultez « Accès à l’interpréteur de commandes d’administration (SSH) ».
Pour désigner votre organisation en tant qu’emplacement de stockage des actions groupées, utilisez la commande ghe-config, en ORGANIZATION remplaçant par le nom de votre organisation.
```
ghe-config app.actions.actions-org ORGANIZATION
```
et
```
ghe-config app.actions.github-org ORGANIZATION
```
Pour ajouter les actions groupées à votre organisation, annulez le SHA.
```
ghe-config --unset 'app.actions.actions-repos-sha1sum'
```
Appliquez la configuration.
```
ghe-config-apply
```

Une fois ces étapes terminées, vous pouvez reprendre la configuration de GitHub Actions à l’étape « Bien démarrer avec GitHub Actions pour GitHub Enterprise Server ».