Cette version de GitHub Enterprise Server ne sera plus disponible le 2026-08-25. Les versions abandonnées ne sont pas prises en charge. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités dans GitHub Enterprise Server, consultez Overview du processus de mise à niveau. Pour obtenir de l’aide sur la mise à niveau, GitHub Support Entreprise.

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

Résolution des problèmes courants qui se produisent lors de l’utilisation GitHub Actions de 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’état de GitHub Actions

Vous pouvez vérifier l’état de GitHub Actions sur votre instance GitHub Enterprise Server à l’aide de 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 des exécuteurs auto-hébergés en utilisant 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é puisse se connecter à un GitHub Enterprise Server à l’aide d’un certificat auto-signé, vous devez installer le certificat sur la machine de l’exécuteur afin de sécuriser la connexion.

Pour les étapes nécessaires pour installer un certificat, consultez la documentation du système d'exploitation de votre runner.

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 pouvez recevoir des erreurs telles que Resource unexpectedly moved to https://IP-ADDRESS lors de la définition ou de la modification de votre GitHub Actions configuration.

Les runners ne se connectent 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 sur votre instance, les exécuteurs auto-hébergés ne pourront pas se connecter à l’ancien nom d’hôte et n’exécuteront pas de travaux.

Vous devez mettre à jour la configuration de vos exécuteurs auto-hébergés pour utiliser le nouveau nom d’hôte pour 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 le runner de GitHub Enterprise Server à l’aide de l’interface utilisateur, puis ajoutez-le de nouveau. 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 échecs lorsque Dependabot déclenche des flux de travail existants

Après avoir configuré les mises à jour Dependabot pour votre instance GitHub Enterprise Server, des échecs peuvent se produire lorsque les flux de travail existants sont déclenchés par des événements Dependabot.

Par défaut, les exécutions de workflow GitHub Actions déclenchées par Dependabot à partir d’événements push, pull_request, pull_request_review ou pull_request_review_comment sont traitées comme si elles provenaient d’un 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. Cela entraîne l’échec des flux de travail qui tentent d’écrire dans le référentiel lorsqu’ils sont déclenchés par Dependabot.

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

  1. Vous pouvez mettre à jour vos flux de travail afin qu’ils ne soient plus déclenchés Dependabot à l’aide d’une expression comme : if: github.actor != 'dependabot[bot]'. Pour plus d’informations, consultez « Évaluer des 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 définir des workflows déclenchés par l’accès à des secrets Dependabot et permettre au paramètre permissions d’étendre la portée par défaut du GITHUB_TOKEN. Pour plus d’informations, consultez Fournir des flux de travail déclenchés par Dependabot l’accès aux secrets et des autorisations accrues ci-dessous.

Fournir des flux de travail déclenchés par Dependabot l’accès aux secrets et par des autorisations accrues

  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 restrictions des flux de travail 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 dans 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 GitHub ActionsGitHub Enterprise Server, vous pouvez résoudre le problème en installant les actions groupées officielles et les modèles de flux de travail.

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

Pour installer les actions groupées officielles et les modèles de flux de travail au sein d’une organisation GitHub Enterprise Serverdésignée, 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 sur Prise en main de GitHub Actions pour GitHub Enterprise Server.