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

Résolution des problèmes courants qui se produisent durant l’utilisation de GitHub Actions sur GitHub Enterprise Server.

Qui peut utiliser cette fonctionnalité ?

Site administrators can troubleshoot GitHub Actions issues and modify GitHub Enterprise Server configurations.

Dans cet article

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

Warning

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

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 :

  1. 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 ».
  2. 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 « Résolution des problèmes de Dependabot sur GitHub Actions ».
  3. 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

  1. 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) ».

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

  3. Appliquez la configuration.

    ghe-config-apply

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

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

  2. 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) ».

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

  4. Pour ajouter les actions groupées à votre organisation, annulez le SHA.

    ghe-config --unset 'app.actions.actions-repos-sha1sum'

  5. 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 ».