Configurations GitHub Actions

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

Secrets dans GitHub Actions

Créez des secrets (informations d’identification) dans le référentiel ou GitHub l’organisationGitHub. Les secrets sont des variables environnementales (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 de l’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 de l’outil GitHub créé dans DevOps (paramètre devops-integration-token ). Pour accéder à votre jeton secret, accédez à votre GitHub enregistrement d’outil dans ServiceNow (Tous les outils > > Outils d’orchestration) et 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 référentiel doivent avoir une 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 syntaxe des workflows 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 sous le répertoire .github/workflows de votre référentiel.

  

• 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 un workflow manuellement.

  

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

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

Les détails suivants sont envoyés à l’instance lorsqu’un ServiceNow workflow est exécuté manuellement ou déclenché automatiquement sur un GitHub référentiel.

• Le webhook workflow_job notifie l’instance ServiceNow avec l’état de la tâche (mis 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 l’état ServiceNow de la tâche (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, et ServiceNow DevOps des étapes de pipeline et des 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 du workflow.
• Vous pouvez utiliser l’interface utilisateur de pipeline pour visualiser les interactions et les résultats d’une exécution de pipeline.

GitHub Exécutions à nouveau

Les demandes de changement créées pour GitHub les tâches sont réutilisées si les demandes de changement sont dans les étapes d’implémentation et post-implémentation. Par exemple, pour une exécution de pipeline :

• Si un travail échoue avant que la demande de changement ne soit à l’étape d’implémentation, la demande de changement créée ne sera pas réutilisée lors de la nouvelle exécution des travaux 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 un travail échoue alors que la demande de changement est dans les étapes d’implémentation ou de post-implémentation, la demande de changement sera réutilisée lorsque les tâches ayant échoué ou toutes les tâches seront 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 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 changement se trouve dans le workflow enfant, le job-name paramètre de l’étape de changement doit être au format job-name : « <parent-workflow-name > / <child-workflow-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

GitHub ActionsLimites de l’intégration Changements de vélocité DevOps

• GitHub Actions et GitHub les environnements sont pris en charge dans GitHub Enterprise le serveur à partir de la version 3.3.
  • Pour plus d’informations sur GitHub les environnements, consultez Utilisation d’environnements pour le déploiement.
  • GitHub environnements sont disponibles pour les référentiels privés uniquement 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 des 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 utilisant 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 est uniquement prise en charge avec GitHub Actions la ServiceNow fonctionnalité Portails de déploiement. Toutefois, la création de changement est possible à la fois 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