Configurations GitHub Actions

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.

  

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

  

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

  

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

  

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

  

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

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 plus d’informations sur GitHub les environnements, voir Utilisation des environnements pour le déploiement.
  • GitHub les environnements ne sont disponibles pour les référentiels privés que dans le GitHub Enterprise Cloud.
• 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.

Tâches associées

• Configurer manuellement les webhooks GitHub