---
sourceDocument: Gestion des services IT Australie
sourceDocumentLink: https://servicenow-prod.fluidtopics.net/r/fr-FR/it-service-management

 Release :

    - australia

ft:locale :

    - fr-FR

ft:publication_title :

    - Gestion des services IT Australie

ft:clusterId :

    - itsm

bundleId :

    - itsm

workflow :

    - Technology


---

# Configurations de GitHub Actions

# Configurations de GitHub Actions {#ariaid-title1}

* Rversion finale: Australia
* 
* Mis à jour 20 avr. 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 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 {#github-actions-integration-with-devops__section_acb_rsz_gwb}

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](https://docs.github.com/en/actions/security-guides/encrypted-secrets).
{#github-actions-integration-with-devops__table_i1t_zt5_h5b__entry__2}

| 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 <kbd class="ph userinput">devops-integration-token</kbd>). 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. |
[ ]

{#github-actions-integration-with-devops__table_i1t_zt5_h5b}

## Workflows dans le référentiel GitHub {#github-actions-integration-with-devops__section_hj5_5rk_xwb}

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](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-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 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.

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

{#github-actions-integration-with-devops__ul_mxh_zrk_xwb}

## Détails d'exécution du workflow GitHub Actions dans DevOps {#github-actions-integration-with-devops__section_q23_ftk_xwb}

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.
{#github-actions-integration-with-devops__ul_n1m_q3v_h5b}

## Nouvelles exécutions GitHub {#github-actions-integration-with-devops__section_exc_5pz_xbc}

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.
{#github-actions-integration-with-devops__ul_ytm_mrz_xbc}

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

## Limitations GitHub Actions pour l'intégration de Vélocité de changement DevOps {#github-actions-integration-with-devops__section_dbt_x2g_hwb}

* 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](https://docs.github.com/en/actions/deployment/targeting-different-environments/using-environments-for-deployment).
  * Les environnements GitHub sont disponibles pour les référentiels privés uniquement dans GitHub Enterprise Cloud.
  {#github-actions-integration-with-devops__ul_bdm_htb_3bc}
* 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.
{#github-actions-integration-with-devops__ul_th5_dgc_35b}
**Tâches associées**   

* [Configurer manuellement des webhooks dans GitHub](https://servicenow-prod.fluidtopics.net/9Pqjw7eqxO95TfkY_cGGXQ "Configurez des webhooks dans GitHub pour envoyer des notifications de synchronisation à l'application Vélocité de changement DevOps.")