Configurations GitHub Actions

  • Rversion finale: Zurich
  • Mis à jour 31 juil. 2025
  • 4 minutes de lecture

    • Informations de configuration le GitHub Actions, telles que les secrets, les workflows et les limitations.

    Clés secrètes dans GitHub Actions

    Créez des secrets (informations d’identification) dans le référentiel ou GitHub l’organisationGitHub. Les secrets sont des variables d’environnement (chiffrées) que vous créez dans une organisation ou un référentiel. Ces secrets peuvent être utilisés dans GitHub Actions les workflows. Pour plus d’informations, consultez Secrets chiffrés.

    Clé secrète Description
    SN_INSTANCE_URL ServiceNow URL d’instance. Par exemple, https://<instance_name>.service-now.com.
    SN_ORCHESTRATION_TOOL_ID Sys_id de l’outil créé dans ServiceNow l’instanceGitHub.
    SN_DEVOPS_INTEGRATION_TOKEN Jeton secret pour l’outil GitHub créé dans DevOps (paramètre devops-integration-token ). Pour accéder à votre jeton secret, accédez à l’enregistrement de votre GitHub outil dans ServiceNow (Tous les outils > > Outils d’orchestration), puis sélectionnez Copier le jeton dans l’interface utilisateur classique.

    Workflows dans le GitHub référentiel

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

    Les points suivants doivent être pris en compte lors de la définition du workflow :
    • Tous les workflows de votre dépôt doivent avoir une extension de fichier .yml ou .yaml. Tous les workflows doivent être sous le répertoire .github/workflows et suivre la syntaxe définie dans la syntaxe du workflow pour GitHub Actions.

      Workflows dans l’onglet GitHub Actions

    • 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 dépôt.

      Placement des fichiers de workflow dans l’onglet Actions

    • Un nom d’affichage doit être donné pour chaque tâche et 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 manuellement un workflow.

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

    GitHub Actions Détails de l’exécution du workflow dans DevOps

    Une fois les webhooks configurés, les notifications sont GitHub Actions envoyées chaque ServiceNow DevOps fois qu’un workflow 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 GitHub référentiel.
    • Le webhook workflow_job informe l’instance ServiceNow de l’état de la tâche (mise en file d’attente, in_progress, terminé) lorsque le workflow est exécuté manuellement ou déclenché automatiquement sur un GitHub référentiel.
    • Les événements entrants sont créés dans l’instance pour le ServiceNow statut de la tâche (mis en file d’attente, in_progress et terminé) et in_progress événements sont ignorés.
    • Les événements entrants mis en file d’attente et terminés sont traités. ServiceNow DevOps Les étapes de pipeline et les tâches d’orchestration 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 de workflow.
    • Vous pouvez utiliser l’interface utilisateur du pipeline pour visualiser les interactions et les résultats dans une exécution de pipeline.

    GitHub Exécutions répétées

    Les demandes de changement créées pour GitHub les tâches sont réutilisées si les demandes de changement sont à l’état 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 Implémentation, la demande de changement créée ne sera pas réutilisée lorsque les tâches ayant échoué seront réexécutées.
    • 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 est à l’étape de l’implémentation ou de post-implémentation, la demande de changement est réutilisée lorsque les tâches ayant échoué ou toutes les tâches sont réexécutées.
      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 du pipeline ne sera pas arrêtée pendant les réexécutions. La demande de changement est considérée comme ayant déjà été approuvée et implémentée.

    Workflows composites

    Pour les workflows composites où un workflow appelle un autre workflow et où l’étape de changement 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 de nom de tâche dans le workflow enfant
    Exemple de paramètre de nom de tâche.

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

    • GitHub Actions et GitHub Les environnements sont pris en charge dans Server à GitHub Enterprise partir de la version 3.3.
    • Pour GitHub les organisations, utilisez un compte spécifique (avec accès aux organisations requises) avec un jeton d’accès personnel pour l’intégration ServiceNow DevOps ou vous pouvez également utiliser les GitHub applications via le code d’autorisation 2.0 ou JWT.

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

    • Seuls les derniers GitHub Actions résultats d’analyse peuvent être extraits d’une instance pour une exécution de workflow.
    • ServiceNow DevOps L’automatisation des changements à l’aide d’une action ou d’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 notification webhook ne contient pas d’informations sur les tâches exécutées en parallèle, ainsi qu’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 interrompre et reprendre l’exécution du workflow à partir de l’instance est prise en charge uniquement avec GitHub Actions la ServiceNow fonctionnalité Portails de déploiement. Toutefois, la création de changement est possible via les portails de déploiement et l’action personnalisée GitHub.
    • L’utilisateur qui crée GitHub l’outil dans l’instance ServiceNow doit être un réviseur pour approuver le workflow pour GitHub les environnements.