Configurations de GitHub Actions

  • Rversion finale: Australia
  • Mis à jour 20 avr. 2026
  • 4 minutes de lecture

    • Informations de configuration sur GitHub Actions, notamment les clés secrètes, les workflows et les limitations.

    Clés secrètes dans GitHub Actions

    Créez des clés secrètes (informations d'identification) dans le référentiel GitHub ou l'organisation GitHub. Les clés secrètes sont des variables d'environnement (chiffrées) que vous créez dans une organisation ou un référentiel. Vous pouvez les utiliser dans les workflows GitHub Actions. Pour plus d'informations, consultez Clés secrètes chiffrées.

    Clé secrète Description
    SN_INSTANCE_URL URL de l'instance ServiceNow. Par exemple, https://<nom_instance>.service-now.com.
    SN_ORCHESTRATION_TOOL_ID Sys_id de l'outil GitHub créé dans l'instance ServiceNow.
    SN_DEVOPS_INTEGRATION_TOKEN Jeton secret de l'outil GitHub créé dans DevOps (paramètre devops-integration-token). Pour connaître votre jeton secret, accédez à votre enregistrement d'outil GitHub dans ServiceNow (Tous > Outils > Outils d'orchestration), et sélectionnez Copier le jeton dans l'interface utilisateur classique.
    Remarque :
    Le secret SN_DEVOPS_INTEGRATION_TOKEN doit être mis à jour manuellement avec le nouveau jeton pour garantir la réussite de l’authentification.

    Workflows dans le référentiel GitHub

    Créez un fichier YAML pour définir la configuration du workflow dans votre référentiel GitHub.

    Tenez compte des points suivants lors de la définition du workflow :
    • Tous les workflows de votre référentiel doivent porter l'extension de fichier .yml ou .yaml. Tous les workflows doivent se trouver dans le répertoire .github/workflows et suivre la syntaxe définie dans la section Syntaxe des workflows pour Actions GitHub.

      Workflows dans l'onglet Actions GitHub

    • Le nom du workflow doit correspondre au nom du fichier de workflow.

      Le nom du workflow doit correspondre au nom du fichier

    • Les noms des workflows sous Tous les workflows de l'onglet Actions doivent correspondre aux workflows enregistrés dans le répertoire .github/workflows de votre référentiel.

      Placement des fichiers de workflow dans l'onglet Actions

    • Vous devez fournir le nom d'affichage pour chaque tâche, qui doit être unique pour chaque tâche du workflow. Le nom de la tâche doit correspondre au nom de l'étape dans l'action personnalisée.

      Nom de la tâche dans l'action personnalisée

    • Utilisez l'événement workflow_dispatch pour déclencher un workflow manuellement.

      Déclenchement manuel d'un workflow à l'aide d'un événement

    Détails d'exécution du workflow GitHub Actions dans DevOps

    Une fois les webhooks configurés, les notifications de GitHub Actions sont envoyées chaque fois qu'un workflow ServiceNow DevOps est exécuté ou déclenché.

    Les détails suivants sont envoyés à l'instance ServiceNow lorsqu'un workflow est exécuté manuellement ou déclenché automatiquement sur un référentiel GitHub.
    • Le webhook workflow_job notifie l'instance ServiceNow avec l'état de la tâche (en file d'attente, en cours, terminé) lorsque le workflow est exécuté manuellement ou déclenché automatiquement sur un référentiel GitHub.
    • Les événements entrants sont créés dans l'instance ServiceNow pour l'état de la tâche (en file d'attente, en cours et terminé) et les événements en cours sont ignorés.
    • Les événements entrants mis en file d'attente et terminés sont traités, et les étapes de pipeline et les tâches d'orchestration ServiceNow DevOps sont créées pour les tâches configurées dans le workflow.
    • L'exécution de pipeline est créée pour chaque exécution de workflow avec des enregistrements d'exécutions de tâches et d'exécutions d'étapes créés pour chaque tâche exécutée dans l'exécution du workflow.
    • Vous pouvez utiliser l'interface utilisateur de pipeline pour visualiser les interactions et les résultats d'une exécution de pipeline.

    Nouvelles exécutions GitHub

    Les demandes de changement créées pour les tâches GitHub sont réutilisées si les demandes de changement se trouvent dans les étapes d'implémentation et de post-implémentation. Par exemple, pour une exécution de pipeline :
    • Si une tâche échoue avant que la demande de changement ne soit à l'étape d'implémentation, la demande de changement créée n'est pas réutilisée lors d'une nouvelle exécution des tâches ayant échoué.
    • Si les tâches ayant échoué ou toutes les tâches sont réexécutées, une nouvelle demande de changement est créée.
    • Désormais, si une tâche échoue alors que la demande de changement se trouve dans les étapes d'implémentation ou de post-implémentation, la demande de changement est réutilisée lors d'une nouvelle exécution des tâches ayant échoué ou de toutes les tâches.
      Remarque :
      Si la demande de changement est déjà implémentée dans une étape précédente avant l'échec de la tâche, l'exécution de pipeline n'est pas interrompue pendant les nouvelles exécutions. La demande de changement est considérée comme déjà approuvée et implémentée.

    Workflows composites

    Pour les workflows composites où un workflow appelle un autre workflow et où l’étape de modification se trouve dans le workflow enfant, le job-name paramètre de l’étape de changement doit être au format job-name : « <parent-job-name> / <child-job-name > ». Ici, l'espace avant et après la barre oblique (/) est obligatoire.

    Figure 1. Exemple d'un paramètre job-name dans le workflow enfant
    Exemple de paramètre de nom de tâche.

    Limitations GitHub Actions pour l'intégration de Vélocité de changement DevOps

    • Les environnements GitHub Actions et GitHub sont pris en charge dans GitHub Enterprise Server à partir de la version 3.3.
      • Pour obtenir des informations détaillées sur les environnements GitHub, consultez Utiliser des environnements pour le déploiement.
      • Les environnements GitHub sont disponibles pour les référentiels privés uniquement dans GitHub Enterprise Cloud.
    • Pour Organisations GitHub, utilisez un compte spécifique (avec accès aux organisations requises) avec un jeton d'accès personnel pour l'intégration à ServiceNow DevOps ; vous pouvez également utiliser des applications GitHub via le code d'autorisation 2.0 ou JWT.

      Pour la création d'outils à l'aide de Applications GitHub - JWT, vous devez créer un outil distinct pour une organisation distincte.

    • Seuls les derniers résultats d'analyse GitHub Actions peuvent être extraits d'une instance pour une exécution de workflow.
    • L'automatisation des changements ServiceNow DevOps avec une action ou un environnement personnalisé n'est pas prise en charge pour les tâches parallèles. Pour les tâches parallèles, la charge utile de la notification webhook ne contient pas d'informations sur les tâches exécutées en parallèle avec un numéro de séquence. En raison de cette limitation, la séquence des tâches dépend de l'ordre d'exécution renvoyé par la réponse de l'API (/repos/{owner}/{repo}/actions/runs/{run_id}/jobs).
    • L'URL de rappel pour mettre en pause et reprendre l'exécution du workflow à partir de l'instance ServiceNow est uniquement prise en charge avec la fonctionnalité Portails de déploiement GitHub Actions. Toutefois, la création de changements est possible à la fois via les portails de déploiement et l'action personnalisée GitHub.
    • L'utilisateur qui crée l'outil GitHub dans l'instance ServiceNow doit être un réviseur pour approuver le workflow pour les environnements GitHub.