À propos des événements qui déclenchent des workflows
Les déclencheurs de workflow sont des événements qui entraînent l'exécution d'un workflow. Pour plus d'informations sur l'utilisation de déclencheurs de workflow, consultez « Déclenchement d’un workflow ».
Certains événements ont plusieurs types d'activités. Pour ces événements, vous pouvez spécifier les types d'activités qui déclenchent une exécution de workflow. Pour plus d'informations sur ce que signifie chaque type d'activité, consultez « Événements et charges utiles du webhook ».
Remarque : Tous les événements de webhook ne déclenchent pas de workflows.
branch_protection_rule
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
branch_protection_rule | - created - edited - deleted | Dernier commit sur la branche par défaut | Branche par défaut |
Remarque : Plusieurs types d’activités déclenchent cet événement. Pour plus d'informations sur chaque type d'activité, consultez « Événements et charges utiles du webhook ». Par défaut, tous les types d’activités déclenchent des workflows qui s’exécutent sur cet événement. Vous pouvez limiter vos exécutions de workflow à des types d’activités spécifiques à l’aide du mot clé types
. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Exécute votre workflow lorsque des règles de protection de branche dans le dépôt de workflow sont modifiées. Pour plus d'informations sur les règles de protection de branche, consultez « À propos des branches protégées ». Pour plus d’informations sur les API de règle de protection de branche, consultez « Objets » dans la documentation sur l’API GraphQL ou « Points de terminaison d’API REST pour les branches et leurs paramètres ».
Par exemple, vous pouvez exécuter un workflow lorsqu'une règle de protection de branche a été créée (created
) ou supprimée (deleted
) :
on:
branch_protection_rule:
types: [created, deleted]
check_run
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
check_run | - created - rerequested - completed - requested_action | Dernier commit sur la branche par défaut | Branche par défaut |
Remarque : Plusieurs types d’activités déclenchent cet événement. Pour plus d'informations sur chaque type d'activité, consultez « Événements et charges utiles du webhook ». Par défaut, tous les types d’activités déclenchent des workflows qui s’exécutent sur cet événement. Vous pouvez limiter vos exécutions de workflow à des types d’activités spécifiques à l’aide du mot clé types
. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Exécute votre workflow lorsqu'une activité liée à une exécution de vérification se produit. Une exécution de vérification est un test individuel qui fait partie d'une suite de vérifications. Pour plus d'informations, consultez « Utilisation de l’API REST pour interagir avec des vérifications ». Pour plus d’informations sur les API d’exécution de vérification, consultez « Objets » dans la documentation sur l’API GraphQL ou « Points de terminaison d’API REST pour les exécutions de vérifications ».
Par exemple, vous pouvez exécuter un workflow lorsqu'une exécution de vérification a été redemandée (rerequested
) ou terminée (completed
).
on:
check_run:
types: [rerequested, completed]
check_suite
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
check_suite | - completed | Dernier commit sur la branche par défaut | Branche par défaut |
Remarque : Plusieurs types d’activités déclenchent cet événement. Pour plus d'informations sur chaque type d'activité, consultez « Événements et charges utiles du webhook ». Même si seul le type d'activité completed
est pris en charge, la spécification du type d'activité maintient votre workflow spécifique si d'autres types d'activité sont ajoutés par la suite. Par défaut, tous les types d’activités déclenchent des workflows qui s’exécutent sur cet événement. Vous pouvez limiter vos exécutions de workflow à des types d’activités spécifiques à l’aide du mot clé types
. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Remarque : Pour empêcher les workflows récursifs, cet événement ne déclenche pas de workflows si la suite de vérifications a été créée par GitHub Actions.
Exécute votre workflow lorsqu'une activité de suite de vérifications se produit. Une suite de vérifications est une collection des exécutions de vérification créées pour un commit spécifique. Les suites de vérifications récapitulent l'état et la conclusion des exécutions de vérification qui se trouvent dans la suite. Pour plus d'informations, consultez « Utilisation de l’API REST pour interagir avec des vérifications ». Pour plus d’informations sur les API des suites de vérifications, consultez « Objets » dans la documentation sur l’API GraphQL ou « Points de terminaison d’API REST pour les suites de vérifications ».
Par exemple, vous pouvez exécuter un workflow lorsqu'une suite de vérifications a été terminée (completed
).
on:
check_suite:
types: [completed]
create
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
create | Non applicable | Dernier commit sur la branche ou l'étiquette créée | Branche ou étiquette créée |
Remarque : Un événement n'est pas créé lorsque vous créez plus de trois étiquettes à la fois.
Exécute votre workflow quand un utilisateur crée une référence Git (branche ou étiquette Git) dans le dépôt du workflow. Pour plus d’informations sur les API permettant de créer une référence Git, consultez « Mutations » dans la documentation sur l’API GraphQL ou « Points de terminaison d’API REST pour les références Git ».
Par exemple, vous pouvez exécuter un workflow lorsque l'événement create
se produit.
on:
create
delete
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
delete | Non applicable | Dernier commit sur la branche par défaut | Branche par défaut |
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Remarque : Un événement n'est pas créé lorsque vous supprimez plus de trois étiquettes à la fois.
Exécute votre workflow quand un utilisateur supprime une référence Git (branche ou étiquette Git) dans le dépôt du workflow. Pour plus d’informations sur les API permettant de supprimer une référence Git, consultez « Mutations » dans la documentation sur l’API GraphQL ou « Points de terminaison d’API REST pour les références Git ».
Par exemple, vous pouvez exécuter un workflow lorsque l'événement delete
se produit.
on:
delete
deployment
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
deployment | Non applicable | Commit à déployer | Branche ou étiquette à déployer (vide en cas de création avec un SHA de commit) |
Exécute votre workflow lorsqu'un utilisateur crée un déploiement dans le dépôt du workflow. Les déploiements créés avec un SHA de commit peuvent ne pas avoir de référence Git. Pour plus d’informations sur les API permettant de créer un déploiement, consultez « Mutations » dans la documentation sur l’API GraphQL ou « Points de terminaison d’API REST pour les référentiels ».
Par exemple, vous pouvez exécuter un workflow lorsque l'événement deployment
se produit.
on:
deployment
deployment_status
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
deployment_status | Non applicable | Commit à déployer | Branche ou étiquette à déployer (vide en cas de commit) |
Remarque : Quand l'état d'un déploiement est défini sur inactive
, aucune exécution de workflow n'est déclenchée.
Exécute votre workflow lorsqu'un tiers fournit un état de déploiement. Les déploiements créés avec un SHA de commit peuvent ne pas avoir de référence Git. Pour plus d’informations sur les API permettant de créer un statut de déploiement, consultez « Mutations » dans la documentation sur l’API GraphQL ou « Points de terminaison d’API REST pour les déploiements ».
Par exemple, vous pouvez exécuter un workflow lorsque l'événement deployment_status
se produit.
on:
deployment_status
discussion
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
discussion | - created - edited - deleted - transferred - pinned - unpinned - labeled - unlabeled - locked - unlocked - category_changed - answered - unanswered | Dernier commit sur la branche par défaut | Branche par défaut |
Remarque : Plusieurs types d’activités déclenchent cet événement. Pour plus d'informations sur chaque type d'activité, consultez « Événements et charges utiles du webhook ». Par défaut, tous les types d’activités déclenchent des workflows qui s’exécutent sur cet événement. Vous pouvez limiter vos exécutions de workflow à des types d’activités spécifiques à l’aide du mot clé types
. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Remarque : Les événements Webhook pour GitHub Discussions sont actuellement en beta et peuvent être amenés à changer.
Exécute votre workflow lorsqu'une discussion dans le dépôt du workflow est créée ou modifiée. Pour les activités liées aux commentaires sur une discussion, utilisez l'événement discussion_comment
. Pour plus d'informations sur les discussions, consultez « À propos des discussions ». Pour plus d'informations sur l'API GraphQL, consultez « Objets ».
Par exemple, vous pouvez exécuter un workflow lorsqu'une discussion a été créée (created
), modifiée (edited
) ou traitée (answered
).
on:
discussion:
types: [created, edited, answered]
discussion_comment
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
discussion_comment | - created - edited - deleted | Dernier commit sur la branche par défaut | Branche par défaut |
Remarque : Plusieurs types d’activités déclenchent cet événement. Pour plus d'informations sur chaque type d'activité, consultez « Événements et charges utiles du webhook ». Par défaut, tous les types d’activités déclenchent des workflows qui s’exécutent sur cet événement. Vous pouvez limiter vos exécutions de workflow à des types d’activités spécifiques à l’aide du mot clé types
. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Remarque : Les événements Webhook pour GitHub Discussions sont actuellement en beta et peuvent être amenés à changer.
Exécute votre workflow lorsqu'un commentaire sur une discussion dans le dépôt du workflow est créé ou modifié. Pour une activité liée à une discussion plutôt qu'à des commentaires sur la discussion, utilisez l'événement discussion
. Pour plus d'informations sur les discussions, consultez « À propos des discussions ». Pour plus d'informations sur l'API GraphQL, consultez « Objets ».
Par exemple, vous pouvez exécuter un workflow lorsqu'un commentaire de discussion a été créé (created
) ou supprimé (deleted
).
on:
discussion_comment:
types: [created, deleted]
fork
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
fork | Non applicable | Dernier commit sur la branche par défaut | Branche par défaut |
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Exécute votre workflow lorsqu'un utilisateur duplique (fork) un dépôt. Pour plus d'informations sur l'API REST, consultez « Points de terminaison d’API REST pour les fourches ».
Par exemple, vous pouvez exécuter un workflow lorsque l'événement fork
se produit.
on:
fork
gollum
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
gollum | Non applicable | Dernier commit sur la branche par défaut | Branche par défaut |
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Exécute votre workflow lorsqu'un utilisateur crée ou met à jour une page Wiki. Pour plus d'informations, consultez « À propos des wikis ».
Par exemple, vous pouvez exécuter un workflow lorsque l'événement gollum
se produit.
on:
gollum
issue_comment
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
issue_comment | - created - edited - deleted | Dernier commit sur la branche par défaut | Branche par défaut |
Remarque : Plusieurs types d’activités déclenchent cet événement. Pour plus d'informations sur chaque type d'activité, consultez « Événements et charges utiles du webhook ». Par défaut, tous les types d’activités déclenchent des workflows qui s’exécutent sur cet événement. Vous pouvez limiter vos exécutions de workflow à des types d’activités spécifiques à l’aide du mot clé types
. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Exécute votre workflow lorsqu'un commentaire sur un problème ou une demande de tirage (pull request) est créé, modifié ou supprimé. Pour plus d'informations sur les API de commentaires sur les problèmes, consultez « Objets » dans la documentation sur l'API GraphQL ou « Événements et charges utiles du webhook » dans la documentation sur l'API REST.
Par exemple, vous pouvez exécuter un workflow lorsqu'un commentaire de problème ou demande de tirage a été créé (created
) ou supprimé (deleted
).
on:
issue_comment:
types: [created, deleted]
issue_comment
sur les problèmes uniquement ou sur les demandes de tirage uniquement
L'événement issue_comment
se produit pour les commentaires à la fois sur les problèmes et sur les demandes de tirage. Vous pouvez utiliser la propriété github.event.issue.pull_request
dans une condition pour effectuer des actions différentes selon que l'objet de déclenchement était un problème ou une demande de tirage.
Par exemple, ce workflow exécute le travail pr_commented
uniquement si l'événement issue_comment
provient d'une demande de tirage. Il exécute le travail issue_commented
uniquement si l'événement issue_comment
provient d'un problème.
on: issue_comment
jobs:
pr_commented:
# This job only runs for pull request comments
name: PR comment
if: ${{ github.event.issue.pull_request }}
runs-on: ubuntu-latest
steps:
- run: |
echo A comment on PR $NUMBER
env:
NUMBER: ${{ github.event.issue.number }}
issue_commented:
# This job only runs for issue comments
name: Issue comment
if: ${{ !github.event.issue.pull_request }}
runs-on: ubuntu-latest
steps:
- run: |
echo A comment on issue $NUMBER
env:
NUMBER: ${{ github.event.issue.number }}
issues
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
issues | - opened - edited - deleted - transferred - pinned - unpinned - closed - reopened - assigned - unassigned - labeled - unlabeled - locked - unlocked - milestoned - demilestoned | Dernier commit sur la branche par défaut | Branche par défaut |
Remarque : Plusieurs types d’activités déclenchent cet événement. Pour plus d'informations sur chaque type d'activité, consultez « Événements et charges utiles du webhook ». Par défaut, tous les types d’activités déclenchent des workflows qui s’exécutent sur cet événement. Vous pouvez limiter vos exécutions de workflow à des types d’activités spécifiques à l’aide du mot clé types
. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Exécute votre workflow lorsqu'un problème dans le dépôt du workflow est créé ou modifié. Pour un activité liée à des commentaires dans un problème, utilisez l'événement issue_comment
. Pour plus d'informations sur les problèmes, consultez « À propos des problèmes ». Pour plus d’informations sur les API de problèmes, consultez « Objets » dans la documentation sur l’API GraphQL ou « Points de terminaison d’API REST pour les problèmes ».
Par exemple, vous pouvez exécuter un workflow lorsqu'un problème a été ouvert (opened
), modifié (edited
) ou jalonné (milestoned
).
on:
issues:
types: [opened, edited, milestoned]
label
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
label | - created - edited - deleted | Dernier commit sur la branche par défaut | Branche par défaut |
Remarque : Plusieurs types d’activités déclenchent cet événement. Pour plus d'informations sur chaque type d'activité, consultez « Événements et charges utiles du webhook ». Par défaut, tous les types d’activités déclenchent des workflows qui s’exécutent sur cet événement. Vous pouvez limiter vos exécutions de workflow à des types d’activités spécifiques à l’aide du mot clé types
. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Exécute votre workflow lorsqu'une étiquette du dépôt de votre workflow est créée ou modifiée. Pour plus d'informations sur les étiquettes, consultez « Gestion des étiquettes ». Pour plus d’informations sur les API d’étiquette, consultez « Objets » dans la documentation sur l’API GraphQL ou « Points de terminaison d’API REST pour les étiquettes ».
Si vous souhaitez exécuter votre workflow lorsqu'une étiquette est ajoutée ou supprimée concernant un problème, une demande de tirage ou une discussion, utilisez plutôt les types d'activités labeled
ou unlabeled
pour les événements issues
, pull_request
, pull_request_target
ou discussion
.
Par exemple, vous pouvez exécuter un workflow lorsqu'une étiquette a été créée (created
) ou supprimée (deleted
).
on:
label:
types: [created, deleted]
merge_group
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
merge_group | checks_requested | SHA du groupe de fusion | Référence du groupe de fusion |
Remarques :
- Plusieurs types d’activités déclenchent cet événement. Même si seul le type d'activité
checks_requested
est pris en charge, la spécification du type d'activité maintient votre workflow spécifique si d'autres types d'activité sont ajoutés par la suite. Pour plus d'informations sur chaque type d'activité, consultez « Événements et charges utiles du webhook ». Par défaut, tous les types d’activités déclenchent des workflows qui s’exécutent sur cet événement. Vous pouvez limiter vos exécutions de workflow à des types d’activités spécifiques à l’aide du mot clétypes
. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ». - Si votre référentiel utilise GitHub Actions pour effectuer des vérifications requises ou si vous avez besoin de workflows via des ensembles de règles d’organisation sur les demandes de tirage dans votre référentiel, vous devez mettre à jour les workflows pour inclure l’événement
merge_group
en tant que déclencheur supplémentaire. Autrement, les vérifications d’état ne seront pas déclenchées lorsque vous ajouterez une demande de tirage à une file d’attente de fusion. La fusion échouera, car la vérification d’état requise ne sera pas signalée. L’événementmerge_group
est distinct des événementspull_request
etpush
.
Exécute votre workflow quand une demande de tirage (pull request) est ajoutée à une file d'attente de fusion, ce qui ajoute la demande de tirage (pull request) à un groupe de fusion. Pour plus d'informations, consultez « Fusion d’une demande de tirage avec une file d’attente de fusion ».
Vous pouvez par exemple exécuter un workflow quand l'activité checks_requested
s'est produite.
on:
pull_request:
branches: [ "main" ]
merge_group:
types: [checks_requested]
milestone
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
milestone | - created - closed - opened - edited - deleted | Dernier commit sur la branche par défaut | Branche par défaut |
Remarque : Plusieurs types d’activités déclenchent cet événement. Pour plus d'informations sur chaque type d'activité, consultez « Événements et charges utiles du webhook ». Par défaut, tous les types d’activités déclenchent des workflows qui s’exécutent sur cet événement. Vous pouvez limiter vos exécutions de workflow à des types d’activités spécifiques à l’aide du mot clé types
. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Exécute votre workflow lorsqu'un jalon dans le dépôt du workflow est créé ou modifié. Pour plus d'informations sur les jalons, consultez « À propos des jalons ». Pour plus d’informations sur les API de jalon, consultez « Objets » dans la documentation sur l’API GraphQL ou « Points de terminaison d’API REST pour les jalons ».
Si vous souhaitez exécuter votre workflow lorsqu'un problème est ajouté ou supprimé concernant un jalon, utilisez plutôt les types d'activités milestoned
ou demilestoned
pour l'événement issues
.
Par exemple, vous pouvez exécuter un workflow lorsqu'un jalon a été ouvert (opened
) ou supprimé (deleted
).
on:
milestone:
types: [opened, deleted]
page_build
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
page_build | Non applicable | Dernier commit sur la branche par défaut | Non applicable |
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Exécute votre workflow lorsqu'un utilisateur effectue des transmissions de type push à une branche qui est la source de publication pour GitHub Pages, si GitHub Pages est activé pour le dépôt. Pour plus d'informations sur les sources de publication GitHub Pages, consultez « Configuration d’une source de publication pour votre site GitHub Pages ». Pour plus d'informations sur l'API REST, consultez « Points de terminaison d’API REST pour les référentiels ».
Par exemple, vous pouvez exécuter un workflow lorsque l'événement page_build
se produit.
on:
page_build
project
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
project | - created - closed - reopened - edited - deleted | Dernier commit sur la branche par défaut | Branche par défaut |
Remarque : Plusieurs types d’activités déclenchent cet événement. Le type d'activité edited
fait référence au moment où un projet (classique), et non une colonne ou une carte sur le projet (classique), est modifié. Pour plus d'informations sur chaque type d'activité, consultez « Événements et charges utiles du webhook ». Par défaut, tous les types d’activités déclenchent des workflows qui s’exécutent sur cet événement. Vous pouvez limiter vos exécutions de workflow à des types d’activités spécifiques à l’aide du mot clé types
. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Remarque : Cet événement se produit uniquement pour les projets appartenant au dépôt du workflow, et non pour les projets appartenant à l'organisation ou à l'utilisateur, ou pour les projets appartenant à un autre dépôt.
Exécute votre workflow lorsqu'un projet (classique) est créé ou modifié. Pour une activité liée aux cartes ou aux colonnes d'un projet (classique), utilisez plutôt les événements project_card
ou project_column
. Pour plus d'informations sur projets (classique), consultez « À propos des projects (classic) ». Pour plus d'informations sur les API de projet (classique), consultez « Objets » dans la documentation sur l'API GraphQL ou « Points de terminaison d’API REST pour Projects (classic) ».
Par exemple, vous pouvez exécuter un workflow lorsqu'un projet a été créé (created
) ou supprimé (deleted
).
on:
project:
types: [created, deleted]
project_card
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
project_card | - created - moved - converted (converti) en problème- edited - deleted | Dernier commit sur la branche par défaut | Branche par défaut |
Remarque : Plusieurs types d’activités déclenchent cet événement. Pour plus d'informations sur chaque type d'activité, consultez « Événements et charges utiles du webhook ». Par défaut, tous les types d’activités déclenchent des workflows qui s’exécutent sur cet événement. Vous pouvez limiter vos exécutions de workflow à des types d’activités spécifiques à l’aide du mot clé types
. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Remarque : Cet événement se produit uniquement pour les projets appartenant au dépôt du workflow, et non pour les projets appartenant à l'organisation ou à l'utilisateur, ou pour les projets appartenant à un autre dépôt.
Exécute votre workflow lorsqu'une carte sur un projet (classique) est créée ou modifiée. Pour l'activité liée à projets (classique) ou aux colonnes d'une projet (classique), utilisez plutôt l'événement project
ou project_column
Pour plus d'informations sur projets (classique), consultez « À propos des projects (classic) ». Pour plus d'informations sur les API de carte de projet, consultez « Objets » dans la documentation sur l'API GraphQL ou « Points de terminaison d’API REST pour les cartes Project (classic) ».
Par exemple, vous pouvez exécuter un workflow lorsqu'une carte de projet a été créée (created
) ou supprimée (deleted
).
on:
project_card:
types: [created, deleted]
project_column
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
project_column | - created - updated - moved - deleted | Dernier commit sur la branche par défaut | Branche par défaut |
Remarque : Plusieurs types d’activités déclenchent cet événement. Pour plus d'informations sur chaque type d'activité, consultez « Événements et charges utiles du webhook ». Par défaut, tous les types d’activités déclenchent des workflows qui s’exécutent sur cet événement. Vous pouvez limiter vos exécutions de workflow à des types d’activités spécifiques à l’aide du mot clé types
. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Remarque : Cet événement se produit uniquement pour les projets appartenant au dépôt du workflow, et non pour les projets appartenant à l'organisation ou à l'utilisateur, ou pour les projets appartenant à un autre dépôt.
Exécute votre workflow lorsqu'une colonne sur un projet (classique) est créée ou modifiée. Pour une activité liée aux projets (classique) ou aux cartes d'un projet (classique), utilisez plutôt l'événement project
ou project_card
. Pour plus d'informations sur projets (classique), consultez « À propos des projects (classic) ». Pour plus d'informations sur les API de colonne de projet, consultez « Objets » dans la documentation sur l'API GraphQL ou « Points de terminaison d’API REST pour Projects (classic) ».
Par exemple, vous pouvez exécuter un workflow lorsqu'une colonne de projet a été créée (created
) ou supprimée (deleted
).
on:
project_column:
types: [created, deleted]
public
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
public | Non applicable | Dernier commit sur la branche par défaut | Branche par défaut |
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Exécute votre workflow lorsque le dépôt de votre workflow passe de privé à public. Pour plus d'informations sur l'API REST, consultez « Points de terminaison d’API REST pour les référentiels ».
Par exemple, vous pouvez exécuter un workflow lorsque l'événement public
se produit.
on:
public
pull_request
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
pull_request | - assigned - unassigned - labeled - unlabeled - opened - edited - closed - reopened - synchronize - converted_to_draft - locked - unlocked - milestoned - demilestoned - ready_for_review - review_requested - review_request_removed - auto_merge_enabled - auto_merge_disabled | Dernier commit de fusion sur la branche GITHUB_REF | Branche de fusion de demande de tirage refs/pull/PULL_REQUEST_NUMBER/merge |
Remarques :
-
Plusieurs types d’activités déclenchent cet événement. Pour plus d'informations sur chaque type d'activité, reportez-vous à« Événements et charges utiles du webhook ». Par défaut, un workflow s'exécute uniquement quand le type d'activité d'un événement
pull_request
estopened
,synchronize
oureopened
. Pour déclencher des workflows selon différents types d'activités, utilisez le mot clétypes
. Pour plus d'informations, consultez « Workflow syntax for GitHub Actions ». -
Les workflows ne s'exécutent pas sur une activité
pull_request
si la demande de tirage (pull request) a un conflit de fusion. Le conflit de fusion doit d'abord être résolu.À l'inverse, les workflows avec l'événement
pull_request_target
s'exécutent même si la demande de tirage a un conflit de fusion. Avant d'utiliser le déclencheurpull_request_target
, vous devez être conscient des risques liés à la sécurité. Pour plus d'informations, consultezpull_request_target
. -
La charge utile de l'événement webhook
pull_request
est vide pour les demandes de tirage (pull request) fusionnées et les demandes de tirage (pull request) provenant de référentiels dupliqués. -
La valeur de
GITHUB_REF
varie pour une demande de tirage fermée selon que la demande de tirage a été fusionnée ou non. Si une demande de tirage a été fermée, mais qu'elle n'a pas été fusionnée, elle estrefs/pull/PULL_REQUEST_NUMBER/merge
. Si une demande de tirage a été fermée à la suite d'une fusion, elle constitue laref
complète de la branche dans laquelle elle a été fusionnée, par exemple/refs/heads/main
.
Exécute votre workflow lorsqu'une activité sur une demande de tirage dans le dépôt du workflow se produit. Par exemple, si aucun type d'activité n'est spécifié, le workflow s'exécute lorsqu'une demande de tirage est ouverte ou rouverte, ou lorsque la branche principale de la demande de tirage est mise à jour. Pour une activité liée aux révisions de demande de tirage, aux commentaires de révision de demande de tirage ou aux commentaires de demande de tirage, utilisez plutôt les événements pull_request_review
, pull_request_review_comment
ou issue_comment
. Pour plus d’informations sur les API de demande de tirage, consultez « Objets » dans la documentation sur l’API GraphQL ou « Points de terminaison d’API REST pour les demandes de tirage (pull request) ».
Notez que pour cet événement, GITHUB_SHA
est le dernier commit de fusion de la branche de fusion de demande de tirage. Si vous souhaitez obtenir l'ID du dernier commit dans la branche principale de la demande de tirage, utilisez github.event.pull_request.head.sha
à la place.
Par exemple, vous pouvez exécuter un workflow lorsqu'une demande de tirage a été ouverte ou rouverte.
on:
pull_request:
types: [opened, reopened]
Vous pouvez utiliser le contexte d'événement pour mieux contrôler le moment où les travaux de votre workflow s'exécutent. Par exemple, ce workflow s'exécute lorsqu'une révision est demandée sur une demande de tirage, mais le travail specific_review_requested
s'exécute uniquement lorsqu'une révision par octo-team
est demandée.
on:
pull_request:
types: [review_requested]
jobs:
specific_review_requested:
runs-on: ubuntu-latest
if: ${{ github.event.requested_team.name == 'octo-team'}}
steps:
- run: echo 'A review from octo-team was requested'
Exécution de votre workflow pull_request
en fonction de la branche de tête ou de base d'une demande de tirage
Vous pouvez utiliser le filtre branches
ou branches-ignore
afin de configurer votre workflow pour qu'il s'exécute uniquement sur les demandes de tirage qui ciblent des branches spécifiques. Pour plus d'informations, consultez « Workflow syntax for GitHub Actions ».
Par exemple, ce workflow s'exécute lorsqu'un utilisateur ouvre une demande de tirage qui cible une branche dont le nom commence par releases/
:
on:
pull_request:
types:
- opened
branches:
- 'releases/**'
Remarque : Si vous utilisez à la fois le filtre branches
et le filtre paths
, le workflow s’exécute uniquement quand les deux filtres sont satisfaits. Par exemple, le workflow suivant s'exécute uniquement lorsqu'une demande de tirage qui inclut une modification apportée à un fichier JavaScript (.js
) est ouverte sur une branche dont le nom commence par releases/
:
on:
pull_request:
types:
- opened
branches:
- 'releases/**'
paths:
- '**.js'
Pour exécuter un travail en fonction du nom de branche principale de la demande de tirage (plutôt que du nom de branche de base de la demande de tirage), utilisez le contexte github.head_ref
dans une condition. Par exemple, ce workflow s'exécute chaque fois qu'une demande de tirage est ouverte, mais le travail run_if
s'exécute uniquement si la tête de la demande de tirage est une branche dont le nom commence par releases/
:
on:
pull_request:
types:
- opened
jobs:
run_if:
if: startsWith(github.head_ref, 'releases/')
runs-on: ubuntu-latest
steps:
- run: echo "The head of this PR starts with 'releases/'"
Exécution de votre workflow pull_request
en fonction des fichiers modifiés dans une demande de tirage
Vous pouvez également configurer votre workflow pour qu'il s'exécute lorsqu'une demande de tirage modifie des fichiers spécifiques. Pour plus d'informations, consultez « Workflow syntax for GitHub Actions ».
Par exemple, ce workflow s'exécute lorsqu'une demande de tirage inclut une modification apportée à un fichier JavaScript (.js
) :
on:
pull_request:
paths:
- '**.js'
Remarque : Si vous utilisez à la fois le filtre branches
et le filtre paths
, le workflow s’exécute uniquement quand les deux filtres sont satisfaits. Par exemple, le workflow suivant s'exécute uniquement lorsqu'une demande de tirage qui inclut une modification apportée à un fichier JavaScript (.js
) est ouverte sur une branche dont le nom commence par releases/
:
on:
pull_request:
types:
- opened
branches:
- 'releases/**'
paths:
- '**.js'
Exécution de votre workflow pull_request
quand une demande de tirage fusionne
Lorsqu'une demande de tirage fusionne, elle est automatiquement fermée. Pour exécuter un workflow lorsqu'une demande de tirage fusionne, utilisez le type d'événement pull_request
closed
avec une condition qui vérifie la valeur merged
de l'événement. Par exemple, le workflow suivant s'exécute chaque fois qu'une demande de tirage se ferme. Le travail if_merged
s'exécute uniquement si la demande de tirage a également été fusionnée.
on:
pull_request:
types:
- closed
jobs:
if_merged:
if: github.event.pull_request.merged == true
runs-on: ubuntu-latest
steps:
- run: |
echo The PR was merged
Workflows dans des dépôts dupliqués
Les workflows ne s’exécutent pas dans des dépôts dupliqués par défaut. Vous devez activer GitHub Actions sous l’onglet Actions du dépôt dupliqué.
À l’exception de GITHUB_TOKEN
, les secrets ne sont pas transmis à l’exécuteur lorsqu’un workflow est déclenché à partir d’un référentiel dupliqué. Le GITHUB_TOKEN
dispose d’autorisations en lecture seule dans les demandes de tirage (pull request) des dépôts dupliqués (fork). Pour plus d’informations, consultez « Authentification par jeton automatique ».
Événements de demande de tirage pour des dépôts dupliqués
Pour des demandes de tirage d’un dépôt dupliqué au dépôt de base, GitHub Enterprise Server envoie les événements pull_request
, issue_comment``pull_request_review_comment
, pull_request_review
et pull_request_target
au dépôt de base. Aucun événement de demande de tirage ne se produit sur le dépôt dupliqué.
Pour les demandes de tirage d’un dépôt dupliqué vers un dépôt privé, les workflows s’exécutent uniquement lorsqu’ils sont activés. Consultez « Gestion des paramètres de GitHub Actions pour un dépôt ».
Remarque : les workflows déclenchés par des demandes de tirage Dependabot sont traités comme s’ils provenaient d’un dépôt dupliqué, et sont également sujets à ces restrictions.
pull_request_comment
(utiliser issue_comment
)
Pour exécuter votre workflow lorsqu'un commentaire sur une demande de tirage (et non sur une différence d'une demande de tirage) est créé, modifié ou supprimé, utilisez l'événement issue_comment
. Pour une activité liée aux révisions de demande de tirage ou aux commentaires de révision de demande de tirage, utilisez les événements pull_request_review
ou pull_request_review_comment
.
pull_request_review
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
pull_request_review | - submitted - edited - dismissed | Dernier commit de fusion sur la branche GITHUB_REF | Branche de fusion de demande de tirage refs/pull/PULL_REQUEST_NUMBER/merge |
Remarque : Plusieurs types d’activités déclenchent cet événement. Pour plus d'informations sur chaque type d'activité, consultez « Événements et charges utiles du webhook ». Par défaut, tous les types d’activités déclenchent des workflows qui s’exécutent sur cet événement. Vous pouvez limiter vos exécutions de workflow à des types d’activités spécifiques à l’aide du mot clé types
. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».
Exécute votre workflow lorsqu'une révision de demande de tirage est envoyée, modifiée ou ignorée. Une révision de demande de tirage est un groupe de commentaires de révision de demande de tirage en plus d'un commentaire de corps et d'un état. Pour une activité liée aux commentaires de révision de demande de tirage ou aux commentaires de demande de tirage, utilisez plutôt les événements pull_request_review_comment
ou issue_comment
. Pour plus d’informations sur les API de révision de demande de tirage, consultez « Objets » dans la documentation sur l’API GraphQL ou « Points de terminaison d’API REST pour les demandes de tirage (pull request) ».
Par exemple, vous pouvez exécuter un workflow lorsqu'une révision de demande de tirage a été modifiée (edited
) ou ignorée (dismissed
).
on:
pull_request_review:
types: [edited, dismissed]
Exécution d'un workflow lorsqu'une demande de tirage est approuvée
Pour exécuter votre workflow lorsqu'une demande de tirage a été approuvée, vous pouvez déclencher votre workflow avec le type submitted
d'événement pull_request_review
, puis vérifier l'état de révision avec la propriété github.event.review.state
. Par exemple, ce workflow s'exécute chaque fois qu'une révision de demande de tirage est envoyée, mais le travail approved
s'exécute uniquement si la révision soumise est une révision d'approbation :
on:
pull_request_review:
types: [submitted]
jobs:
approved:
if: github.event.review.state == 'approved'
runs-on: ubuntu-latest
steps:
- run: echo "This PR was approved"
Workflows dans des dépôts dupliqués
Les workflows ne s’exécutent pas dans des dépôts dupliqués par défaut. Vous devez activer GitHub Actions sous l’onglet Actions du dépôt dupliqué.
À l’exception de GITHUB_TOKEN
, les secrets ne sont pas transmis à l’exécuteur lorsqu’un workflow est déclenché à partir d’un référentiel dupliqué. Le GITHUB_TOKEN
dispose d’autorisations en lecture seule dans les demandes de tirage (pull request) des dépôts dupliqués (fork). Pour plus d’informations, consultez « Authentification par jeton automatique ».
Événements de demande de tirage pour des dépôts dupliqués
Pour des demandes de tirage d’un dépôt dupliqué au dépôt de base, GitHub Enterprise Server envoie les événements pull_request
, issue_comment``pull_request_review_comment
, pull_request_review
et pull_request_target
au dépôt de base. Aucun événement de demande de tirage ne se produit sur le dépôt dupliqué.
Pour les demandes de tirage d’un dépôt dupliqué vers un dépôt privé, les workflows s’exécutent uniquement lorsqu’ils sont activés. Consultez « Gestion des paramètres de GitHub Actions pour un dépôt ».
Remarque : les workflows déclenchés par des demandes de tirage Dependabot sont traités comme s’ils provenaient d’un dépôt dupliqué, et sont également sujets à ces restrictions.
pull_request_review_comment
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
pull_request_review_comment | - created - edited - deleted | Dernier commit de fusion sur la branche GITHUB_REF | Branche de fusion de demande de tirage refs/pull/PULL_REQUEST_NUMBER/merge |
Remarque : Plusieurs types d’activités déclenchent cet événement. Pour plus d'informations sur chaque type d'activité, consultez « Événements et charges utiles du webhook ». Par défaut, tous les types d’activités déclenchent des workflows qui s’exécutent sur cet événement. Vous pouvez limiter vos exécutions de workflow à des types d’activités spécifiques à l’aide du mot clé types
. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».
Exécute votre workflow lorsqu'un commentaire de révision de demande de tirage est modifié. Un commentaire de révision de demande de tirage est un commentaire sur la différence d'une demande de tirage. Pour une activité liée aux révisions de demande de tirage ou aux commentaires de demande de tirage, utilisez plutôt les événements pull_request_review
ou issue_comment
. Pour plus d’informations sur les API de commentaire de révision de demande de tirage, consultez « Objets » dans la documentation sur l’API GraphQL ou « Points de terminaison d’API REST pour les demandes de tirage (pull request) ».
Par exemple, vous pouvez exécuter un workflow lorsqu'un commentaire de révision de demande de tirage a été créé (created
) ou supprimé (deleted
).
on:
pull_request_review_comment:
types: [created, deleted]
Workflows dans des dépôts dupliqués
Les workflows ne s’exécutent pas dans des dépôts dupliqués par défaut. Vous devez activer GitHub Actions sous l’onglet Actions du dépôt dupliqué.
À l’exception de GITHUB_TOKEN
, les secrets ne sont pas transmis à l’exécuteur lorsqu’un workflow est déclenché à partir d’un référentiel dupliqué. Le GITHUB_TOKEN
dispose d’autorisations en lecture seule dans les demandes de tirage (pull request) des dépôts dupliqués (fork). Pour plus d’informations, consultez « Authentification par jeton automatique ».
Événements de demande de tirage pour des dépôts dupliqués
Pour des demandes de tirage d’un dépôt dupliqué au dépôt de base, GitHub Enterprise Server envoie les événements pull_request
, issue_comment``pull_request_review_comment
, pull_request_review
et pull_request_target
au dépôt de base. Aucun événement de demande de tirage ne se produit sur le dépôt dupliqué.
Pour les demandes de tirage d’un dépôt dupliqué vers un dépôt privé, les workflows s’exécutent uniquement lorsqu’ils sont activés. Consultez « Gestion des paramètres de GitHub Actions pour un dépôt ».
Remarque : les workflows déclenchés par des demandes de tirage Dependabot sont traités comme s’ils provenaient d’un dépôt dupliqué, et sont également sujets à ces restrictions.
pull_request_target
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
pull_request | - assigned - unassigned - labeled - unlabeled - opened - edited - closed - reopened - synchronize - converted_to_draft - ready_for_review - locked - unlocked - review_requested - review_request_removed - auto_merge_enabled - auto_merge_disabled | Dernier commit sur la branche de base de la demande de tirage | Branche de base de la demande de tirage |
Remarque : Plusieurs types d’activités déclenchent cet événement. Pour plus d'informations sur chaque type d'activité, consultez « Événements et charges utiles du webhook ». Par défaut, un workflow s'exécute uniquement quand le type d'activité d'un événement pull_request_target
est opened
, synchronize
ou reopened
. Pour déclencher des workflows selon différents types d'activités, utilisez le mot clé types
. Pour plus d'informations, consultez « Workflow syntax for GitHub Actions ».
Exécute votre workflow lorsqu'une activité sur une demande de tirage dans le dépôt du workflow se produit. Par exemple, si aucun type d'activité n'est spécifié, le workflow s'exécute lorsqu'une demande de tirage est ouverte ou rouverte, ou lorsque la branche principale de la demande de tirage est mise à jour.
Cet événement s'exécute dans le contexte de la base de la demande de tirage, plutôt que dans le contexte du commit de fusion, comme l'événement pull_request
. Cela empêche l'exécution de code non sécurisé à partir de la tête de la demande de tirage qui pourrait modifier votre dépôt ou voler des secrets que vous utilisez dans votre workflow. Cet événement permet à votre workflow d'effectuer des opérations comme placer des étiquettes ou effectuer des commentaires sur les demandes de tirage à partir de duplications. Évitez d'utiliser cet événement si vous devez générer ou exécuter du code à partir de la demande de tirage.
Pour garantir la sécurité des dépôts, les branches portant des noms qui correspondent à certains modèles (comme ceux qui ressemblent aux SHA) peuvent ne pas déclencher de workflows avec l'événement pull_request_target
.
Avertissement : Pour les workflows déclenchés par l'événement pull_request_target
, l'autorisation d'accès en lecture/écriture au dépôt est accordée à GITHUB_TOKEN
, sauf si la clé permissions
est spécifiée et que le workflow peut accéder aux secrets, même lorsqu'il est déclenché à partir d'une duplication. Même si le workflow s'exécute dans le contexte de la base de la demande de tirage, vous devez vous assurer que vous n'extrayez pas, ne générez pas ou n'exécutez pas du code non approuvé à partir de la demande de tirage avec cet événement. De plus, tous les caches partagent la même étendue que la branche de base. Pour éviter l'empoisonnement du cache, vous ne devez pas enregistrer le cache s'il est possible que le contenu du cache ait été modifié. Pour plus d'informations, consultez « Maintien de la sécurité de votre instance GitHub Actions et vos workflows : Prévention des demandes pwn » sur le site web GitHub Security Lab.
Par exemple, vous pouvez exécuter un workflow lorsqu'une demande de tirage a été attribuée (assigned
), ouverte (opened
), synchronisée (synchronize
) ou rouverte (reopened
).
on:
pull_request_target:
types: [assigned, opened, synchronize, reopened]
Exécution de votre workflow pull_request_target
en fonction de la branche de tête ou de base d'une demande de tirage
Vous pouvez utiliser le filtre branches
ou branches-ignore
afin de configurer votre workflow pour qu'il s'exécute uniquement sur les demandes de tirage qui ciblent des branches spécifiques. Pour plus d'informations, consultez « Workflow syntax for GitHub Actions ».
Par exemple, ce workflow s'exécute lorsqu'un utilisateur ouvre une demande de tirage qui cible une branche dont le nom commence par releases/
:
on:
pull_request_target:
types:
- opened
branches:
- 'releases/**'
Remarque : Si vous utilisez à la fois le filtre branches
et le filtre paths
, le workflow s’exécute uniquement quand les deux filtres sont satisfaits. Par exemple, le workflow suivant s'exécute uniquement lorsqu'une demande de tirage qui inclut une modification apportée à un fichier JavaScript (.js
) est ouverte sur une branche dont le nom commence par releases/
:
on:
pull_request_target:
types:
- opened
branches:
- 'releases/**'
paths:
- '**.js'
Pour exécuter un travail en fonction du nom de branche principale de la demande de tirage (plutôt que du nom de branche de base de la demande de tirage), utilisez le contexte github.head_ref
dans une condition. Par exemple, ce workflow s'exécute chaque fois qu'une demande de tirage est ouverte, mais le travail run_if
s'exécute uniquement si la tête de la demande de tirage est une branche dont le nom commence par releases/
:
on:
pull_request_target:
types:
- opened
jobs:
run_if:
if: startsWith(github.head_ref, 'releases/')
runs-on: ubuntu-latest
steps:
- run: echo "The head of this PR starts with 'releases/'"
Exécution de votre workflow pull_request_target
en fonction des fichiers modifiés dans une demande de tirage
Vous pouvez utiliser le filtre paths
ou paths-ignore
afin de configurer votre workflow pour qu'il s'exécute lorsqu'une demande de tirage modifie des fichiers spécifiques. Pour plus d'informations, consultez « Workflow syntax for GitHub Actions ».
Par exemple, ce workflow s'exécute lorsqu'une demande de tirage inclut une modification apportée à un fichier JavaScript (.js
) :
on:
pull_request_target:
paths:
- '**.js'
Remarque : Si vous utilisez à la fois le filtre branches
et le filtre paths
, le workflow s’exécute uniquement quand les deux filtres sont satisfaits. Par exemple, le workflow suivant s'exécute uniquement lorsqu'une demande de tirage qui inclut une modification apportée à un fichier JavaScript (.js
) est ouverte sur une branche dont le nom commence par releases/
:
on:
pull_request_target:
types:
- opened
branches:
- 'releases/**'
paths:
- '**.js'
Exécution de votre workflow pull_request_target
quand une demande de tirage fusionne
Lorsqu'une demande de tirage fusionne, elle est automatiquement fermée. Pour exécuter un workflow lorsqu'une demande de tirage fusionne, utilisez le type d'événement pull_request_target
closed
avec une condition qui vérifie la valeur merged
de l'événement. Par exemple, le workflow suivant s'exécute chaque fois qu'une demande de tirage se ferme. Le travail if_merged
s'exécute uniquement si la demande de tirage a également été fusionnée.
on:
pull_request_target:
types:
- closed
jobs:
if_merged:
if: github.event.pull_request.merged == true
runs-on: ubuntu-latest
steps:
- run: |
echo The PR was merged
push
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
push | Non applicable | Quand vous supprimez une branche, le SHA dans l'exécution du workflow(et ses références associées) revient à la branche par défaut du dépôt. | Référence mise à jour |
Remarque : La charge utile du webhook disponible pour GitHub Actions n'inclut pas les attributs added
, removed
et modified
dans l'objet commit
. Vous pouvez récupérer l'objet de commit complet à l'aide de l'API. Pour plus d’informations, consultez « Objets » dans la documentation sur l’API GraphQL ou « Points de terminaison d’API REST pour les commits »
Remarque : les événements ne seront pas créés pour les balises lorsque plus de trois balises sont envoyées en même temps.
Exécute votre workflow lorsque vous envoyez (push) un commit ou une balise, ou lorsque vous créez un référentiel à partir d'un modèle.
Par exemple, vous pouvez exécuter un workflow lorsque l'événement push
se produit.
on:
push
Remarque : Quand un événement de webhook push
déclenche une exécution de workflow, le champ « poussé par » de l'IU d'Actions affiche le compte du pousseur et non celui de l'auteur ou du commiteur. Toutefois, si les changements sont poussés vers un dépôt à l'aide de l'authentification SSH et d'une clé de déploiement, le champ « poussé par » indique l'administrateur de dépôt qui a vérifié la clé de déploiement au moment où elle a été ajoutée à un dépôt.
Exécution de votre workflow uniquement lorsqu'une transmission de type push vers des branches spécifiques se produit
Vous pouvez utiliser le filtre branches
ou branches-ignore
afin de configurer votre workflow pour qu'il s'exécute uniquement lorsque des branches spécifiques sont poussées (par push). Pour plus d'informations, consultez « Workflow syntax for GitHub Actions ».
Par exemple, ce workflow s'exécute quand un utilisateur pousse (par push) vers main
ou vers une branche qui commence par releases/
.
on:
push:
branches:
- 'main'
- 'releases/**'
Remarque : Si vous utilisez à la fois le filtre branches
et le filtre paths
, le workflow s’exécute uniquement quand les deux filtres sont satisfaits. Par exemple, le workflow suivant s'exécute uniquement lorsqu'une transmission de type push qui inclut une modification apportée à un fichier JavaScript (.js
) est effectuée sur une branche dont le nom commence par releases/
:
on:
push:
branches:
- 'releases/**'
paths:
- '**.js'
Exécution de votre workflow uniquement lorsqu'une transmission de type push d'étiquettes spécifiques se produit
Vous pouvez utiliser le filtre tags
ou tags-ignore
pour configurer votre workflow afin qu'il s'exécute uniquement quand des étiquettes spécifiques sont poussées. Pour plus d'informations, consultez « Workflow syntax for GitHub Actions ».
Par exemple, ce workflow s'exécute quand un utilisateur pousse (par push) une étiquette qui commence par v1.
.
on:
push:
tags:
- v1.**
Exécution de votre workflow uniquement lorsqu'une transmission de type push affecte des fichiers spécifiques
Vous pouvez utiliser le filtre paths
ou paths-ignore
afin de configurer votre workflow pour qu'il s'exécute lorsqu'une transmission de type push à des fichiers spécifiques se produit. Pour plus d'informations, consultez « Workflow syntax for GitHub Actions ».
Par exemple, ce workflow s'exécute lorsqu'un utilisateur pousse (par push) une modification à un fichier JavaScript (.js
) :
on:
push:
paths:
- '**.js'
Remarque : Si vous utilisez à la fois le filtre branches
et le filtre paths
, le workflow s’exécute uniquement quand les deux filtres sont satisfaits. Par exemple, le workflow suivant s'exécute uniquement lorsqu'une transmission de type push qui inclut une modification apportée à un fichier JavaScript (.js
) est effectuée sur une branche dont le nom commence par releases/
:
on:
push:
branches:
- 'releases/**'
paths:
- '**.js'
registry_package
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
registry_package | - published - updated | Commit du package publié | Branche ou étiquette du package publié |
Remarque : Plusieurs types d’activités déclenchent cet événement. Pour plus d'informations sur chaque type d'activité, consultez « Événements et charges utiles du webhook ». Par défaut, tous les types d’activités déclenchent des workflows qui s’exécutent sur cet événement. Vous pouvez limiter vos exécutions de workflow à des types d’activités spécifiques à l’aide du mot clé types
. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Remarque : Lors de l'envoi d'images conteneur multi-architectures, cet événement se produit une fois par manifeste, de sorte que vous pouvez observer que votre workflow se déclenche plusieurs fois. Pour atténuer ce problème et exécuter uniquement votre travail de workflow pour l'événement qui contient les informations de balise d'image réelles, utilisez une condition :
jobs:
job_name:
if: ${{ github.event.registry_package.package_version.container_metadata.tag.name != '' }}
Exécute votre workflow lorsqu'une activité liée à GitHub Packages se produit dans votre dépôt. Pour plus d'informations, consultez la « documentation de GitHub Packages ».
Par exemple, vous pouvez exécuter un workflow quand une nouvelle version de package est published
.
on:
registry_package:
types: [published]
release
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
release | - published - unpublished - created - edited - deleted - prereleased - released | Dernier commit dans la version étiquetée | Référence d'étiquette de la version refs/tags/<tag_name> |
Remarque : Plusieurs types d’activités déclenchent cet événement. Pour plus d'informations sur chaque type d'activité, consultez « Événements et charges utiles du webhook ». Par défaut, tous les types d’activités déclenchent des workflows qui s’exécutent sur cet événement. Vous pouvez limiter vos exécutions de workflow à des types d’activités spécifiques à l’aide du mot clé types
. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».
Remarque : Les workflows ne sont pas déclenchés pour les types d'activités created
, edited
ou deleted
pour les versions brouillon. Lorsque vous créez votre version par le biais de l'interface utilisateur du navigateur GitHub Enterprise Server, votre version peut être enregistrée automatiquement en tant que brouillon.
Remarque : Le type prereleased
ne se déclenche pas pour les préversions publiées à partir de versions brouillon, mais le type published
se déclenche. Si vous souhaitez qu'un workflow s'exécute quand les préversions et stables sont publiées, abonnez-vous au type published
plutôt qu'à released
et prereleased
.
Exécute votre workflow lorsqu'une activité de version dans votre dépôt se produit. Pour plus d'informations sur les API de version, consultez « Objets » dans la documentation sur l'API GraphQL ou « Points de terminaison d’API REST pour les versions et les ressources de mise en production » dans la documentation sur l'API REST.
Par exemple, vous pouvez exécuter un workflow lorsqu'une version a été publiée (published
).
on:
release:
types: [published]
repository_dispatch
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
repository_dispatch | Custom | Dernier commit sur la branche par défaut | Branche par défaut |
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Vous pouvez utiliser l'API GitHub Enterprise Server pour déclencher un événement de webhook appelé repository_dispatch
lorsque vous souhaitez déclencher un workflow pour une activité qui se produit en dehors de GitHub Enterprise Server. Pour plus d’informations, consultez « Points de terminaison d’API REST pour les référentiels ».
Lorsque vous effectuez une demande de création d'un événement repository_dispatch
, vous devez spécifier un event_type
pour décrire le type d'activité. Par défaut, tous les types d'activités repository_dispatch
déclenchent l'exécution d'un workflow. Vous pouvez utiliser le mot clé types
pour limiter l'exécution de votre workflow lorsqu'une valeur event_type
spécifique est envoyée dans la charge utile de webhook repository_dispatch
.
on:
repository_dispatch:
types: [test_result]
Remarque : La valeur event_type
de l'étiquette est limitée à 100 caractères.
Toutes les données que vous envoyez via le paramètre client_payload
seront disponibles dans le contexte github.event
de votre workflow. Par exemple, si vous envoyez ce corps de demande lorsque vous créez un événement de répartition de dépôt :
{
"event_type": "test_result",
"client_payload": {
"passed": false,
"message": "Error: timeout"
}
}
Vous pouvez ensuite accéder à la charge utile dans un workflow de la manière suivante :
on:
repository_dispatch:
types: [test_result]
jobs:
run_if_failure:
if: ${{ !github.event.client_payload.passed }}
runs-on: ubuntu-latest
steps:
- env:
MESSAGE: ${{ github.event.client_payload.message }}
run: echo $MESSAGE
Remarques:
- Le nombre maximal de propriétés de niveau supérieur dans
client_payload
est de 10. - La charge utile peut contenir un maximum de 65 535 caractères.
schedule
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
Non applicable | Non applicable | Dernier commit sur la branche par défaut | Branche par défaut |
Remarques :
-
L’événement
schedule
peut être retardé pendant les périodes où les charges des exécutions de workflows GitHub Actions sont élevées. Les périodes de charges élevées incluent le début de chaque heure. Si la charge est suffisamment élevée, certains travaux en file d’attente peuvent être supprimés. Pour réduire le risque de retard, planifiez l’exécution de votre workflow à un autre moment dans l’heure. -
Cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
-
Les flux de travail planifiés s’exécutent uniquement sur le branche par défaut.
-
Dans un dépôt public, les workflows planifiés sont automatiquement désactivés quand aucune activité de dépôt n’a eu lieu pendant 60 jours. Pour plus d’informations sur la réactivation d’un flux de travail désactivé, consultez « Désactivation et activation d’un workflow ».
-
Lorsque le dernier utilisateur à s’être engagé dans la planification cron d’un flux de travail est supprimé de l’organisation, le flux de travail planifié est désactivé. Si un utilisateur disposant des autorisations
write
pour le référentiel effectue une validation qui modifie la planification cron, le flux de travail planifié est réactivé. Notez que, dans ce cas, le flux de travail n’est pas réactivé par toute modification apportée au fichier de flux de travail ; vous devez modifier la valeurcron
et valider cette modification.Exemple :
on: schedule: - cron: "15 4,5 * * *" # <=== Change this value
L'événement schedule
vous permet de déclencher un workflow à une heure planifiée.
Vous pouvez planifier l’exécution d’un workflow à des heures UTC spécifiques à l’aide de la syntaxe cron POSIX. Les workflows planifiés s’exécutent sur le dernier commit de la branche par défaut ou de base. L’intervalle le plus court auquel vous pouvez exécuter des workflows planifiés est une fois toutes les 5 minutes.
Cet exemple déclenche le workflow chaque jour à 5h30 et à 17h30 UTC :
on:
schedule:
# * is a special character in YAML so you have to quote this string
- cron: '30 5,17 * * *'
Un seul workflow peut être déclenché par plusieurs événements schedule
. Vous pouvez accéder à l’événement de planification qui a déclenché le workflow via le contexte github.event.schedule
. Cet exemple déclenche l’exécution du workflow à 5h30 UTC tous les lundis et jeudis, mais ignore l’étape Not on Monday or Wednesday
le lundi et le mercredi.
on:
schedule:
- cron: '30 5 * * 1,3'
- cron: '30 5 * * 2,4'
jobs:
test_schedule:
runs-on: ubuntu-latest
steps:
- name: Not on Monday or Wednesday
if: github.event.schedule != '30 5 * * 1,3'
run: echo "This step will be skipped on Monday and Wednesday"
- name: Every time
run: echo "This step will always run"
La syntaxe cron comporte cinq champs séparés par un espace, chaque champ représentant une unité de temps.
┌───────────── minute (0 - 59)
│ ┌───────────── hour (0 - 23)
│ │ ┌───────────── day of the month (1 - 31)
│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)
│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)
│ │ │ │ │
│ │ │ │ │
│ │ │ │ │
* * * * *
Vous pouvez utiliser ces opérateurs dans n'importe lequel de ces cinq champs :
Opérateur | Description | Exemple |
---|---|---|
* | Valeur quelconque | 15 * * * * s'exécute à chaque minute 15 de chaque heure de chaque jour. |
, | Séparateur de liste de valeurs | 2,10 4,5 * * * s'exécute à la minute 2 et 10 de la 4ème et 5ème heure de chaque jour. |
- | Plage de valeurs | 30 4-6 * * * s'exécute à la minute 30 de la 4ème, 5ème et 6ème heure. |
/ | Valeurs d'étape | 20/15 * * * * s'exécute toutes les 15 minutes de la minute 20 à 59 (minutes 20, 35 et 50). |
Remarque : GitHub Actions ne prend pas en charge la syntaxe @yearly
, @monthly
, @weekly
, @daily
, @hourly
et @reboot
non standard.
Vous pouvez utiliser crontab guru pour générer votre syntaxe cron et vérifier l'heure à laquelle elle s'exécutera. Pour vous aider à commencer, il existe également une liste d'exemples crontab guru.
Les notifications pour les workflows planifiés sont envoyées à l'utilisateur qui a apporté la dernière modification à la syntaxe cron dans le fichier de workflow. Pour plus d'informations, consultez « Notifications pour les exécutions de workflow ».
status
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
status | Non applicable | Dernier commit sur la branche par défaut | Non applicable |
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Exécute votre workflow lorsque l'état d'un commit Git change. Par exemple, les commits peuvent être marqués comme error
, failure
, pending
ou success
. Si vous souhaitez fournir plus de détails sur le changement d'état, vous pouvez utiliser l'événement check_run
. Pour plus d'informations sur les API d'état de commit, consultez « Objets » dans la documentation sur l'API GraphQL ou « Points de terminaison d’API REST pour les commits ».
Par exemple, vous pouvez exécuter un workflow lorsque l'événement status
se produit.
on:
status
Si vous souhaitez exécuter un travail dans votre workflow en fonction du nouvel état de commit, vous pouvez utiliser le contexte github.event.state
. Par exemple, le workflow suivant se déclenche lorsqu'un état de commit change, mais le travail if_error_or_failure
s'exécute uniquement si le nouvel état de commit est error
ou failure
.
on:
status
jobs:
if_error_or_failure:
runs-on: ubuntu-latest
if: >-
github.event.state == 'error' ||
github.event.state == 'failure'
steps:
- env:
DESCRIPTION: ${{ github.event.description }}
run: |
echo The status is error or failed: $DESCRIPTION
watch
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
watch | - started | Dernier commit sur la branche par défaut | Branche par défaut |
Remarque : Plusieurs types d’activités déclenchent cet événement. Même si seul le type d'activité started
est pris en charge, la spécification du type d'activité maintient votre workflow spécifique si d'autres types d'activité sont ajoutés par la suite. Pour plus d'informations sur chaque type d'activité, consultez « Événements et charges utiles du webhook ». Par défaut, tous les types d’activités déclenchent des workflows qui s’exécutent sur cet événement. Vous pouvez limiter vos exécutions de workflow à des types d’activités spécifiques à l’aide du mot clé types
. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Exécute votre workflow lorsque le dépôt du workflow est marqué d'une étoile. Pour plus d’informations sur les API de demande de tirage, consultez « Mutations » dans la documentation sur l’API GraphQL ou « Points de terminaison d’API REST pour l’attribution d’étoiles ».
Par exemple, vous pouvez exécuter un workflow lorsqu'un utilisateur met en vedette un dépôt, qui est le type d'activité started
pour un événement espion.
on:
watch:
types: [started]
workflow_call
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
Identique au workflow appelant | Non applicable | Identique au workflow appelant | Identique au workflow appelant |
workflow_call
est utilisé pour indiquer qu'un workflow peut être appelé par un autre workflow. Lorsqu'un workflow est déclenché avec l'événement workflow_call
, la charge utile d'événement dans le workflow appelé est la même charge utile d'événement que celle du workflow appelant. Pour plus d'informations, consultez « Réutilisation des workflows ».
L'exemple ci-dessous exécute le workflow uniquement lorsqu'il est appelé à partir d'un autre workflow :
on: workflow_call
workflow_dispatch
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
workflow_dispatch | Non applicable | Dernier commit sur l'étiquette ou la branche GITHUB_REF | Branche ou étiquette ayant reçu la distribution |
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Pour activer le déclenchement manuel d'un workflow, vous devez configurer l'événement workflow_dispatch
. Vous pouvez déclencher manuellement une exécution de workflow à l'aide de l'API GitHub Enterprise Server, de GitHub CLI ou de l'interface de navigateur GitHub Enterprise Server. Pour plus d'informations, consultez « Exécution manuelle d’un workflow ».
on: workflow_dispatch
Fourniture d'entrées
Vous pouvez configurer des propriétés d'entrée personnalisées, des valeurs d'entrée par défaut et des entrées requises pour l'événement directement dans votre workflow. Lorsque vous déclenchez l'événement, vous pouvez fournir la valeur ref
et toutes les valeurs inputs
. Lorsque le workflow s’exécute, vous pouvez accéder aux valeurs d’entrée dans le contexte inputs
. Pour plus d’informations, consultez « Accès à des informations contextuelles sur l’exécution d’un workflow ».
Remarques:
- Le workflow recevra également les entrées dans le contexte
github.event.inputs
. Les informations dans le contexteinputs
et le contextegithub.event.inputs
sont identiques, à l’exception du fait que le contexteinputs
conserve les valeurs booléennes en tant que valeurs booléennes au lieu de les convertir en chaînes. Le typechoice
est résolu en chaîne et est une option sélectionnable unique. - Le nombre maximal de propriétés de niveau supérieur pour
inputs
est de 10. - La charge utile maximale pour
inputs
est de 65 535 caractères.
Cet exemple définit des entrées appelées logLevel
, tags
et environment
. Vous passez des valeurs pour ces entrées au workflow lorsque vous l'exécutez. Ce workflow imprime ensuite les valeurs dans le journal, à l’aide des propriétés de contexte inputs.logLevel
, inputs.tags
et inputs.environment
.
on:
workflow_dispatch:
inputs:
logLevel:
description: 'Log level'
required: true
default: 'warning'
type: choice
options:
- info
- warning
- debug
tags:
description: 'Test scenario tags'
required: false
type: boolean
environment:
description: 'Environment to run tests against'
type: environment
required: true
jobs:
log-the-inputs:
runs-on: ubuntu-latest
steps:
- run: |
echo "Log level: $LEVEL"
echo "Tags: $TAGS"
echo "Environment: $ENVIRONMENT"
env:
LEVEL: ${{ inputs.logLevel }}
TAGS: ${{ inputs.tags }}
ENVIRONMENT: ${{ inputs.environment }}
Si vous exécutez ce workflow à partir d'un navigateur, vous devez entrer manuellement des valeurs pour les entrées requises avant l'exécution du workflow.
Vous pouvez également passer des entrées lorsque vous exécutez un workflow à partir d'un script ou à l'aide de GitHub CLI. Par exemple :
gh workflow run run-tests.yml -f logLevel=warning -f tags=false -f environment=staging
Pour plus d'informations, consultez les informations sur GitHub CLI dans « Exécution manuelle d’un workflow ».
workflow_run
Charge utile d'événement de webhook | Types d'activités | GITHUB_SHA | GITHUB_REF |
---|---|---|---|
workflow_run | - completed - requested - in_progress | Dernier commit sur la branche par défaut | Branche par défaut |
Remarque : Plusieurs types d’activités déclenchent cet événement. Le type d'activité requested
ne se produit pas lorsqu'un workflow est réexécuté. Pour plus d'informations sur chaque type d'activité, consultez « Événements et charges utiles du webhook ». Par défaut, tous les types d’activités déclenchent des workflows qui s’exécutent sur cet événement. Vous pouvez limiter vos exécutions de workflow à des types d’activités spécifiques à l’aide du mot clé types
. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».
Remarque : cet événement ne déclenche une exécution du workflow que si le fichier du workflow se trouve sur la branche par défaut.
Remarque : Vous ne pouvez pas utiliser workflow_run
pour chaîner plus de trois niveaux de workflows. Par exemple, si vous tentez de déclencher cinq workflows (nommés B
à F
) pour qu'ils s'exécutent de manière séquentielle après l'exécution d'un workflow initial A
(autrement dit : A
→ B
→ C
→ D
→ E
→ F
), les workflows E
et F
ne sont pas exécutés.
Cet événement se produit lorsqu'une exécution de workflow est demandée ou terminée. Il vous permet d'exécuter un workflow en fonction de l'exécution ou de l'achèvement d'un autre workflow. Le workflow démarré par l'événement workflow_run
est en mesure d'accéder aux secrets et aux jetons d'écriture, même si le workflow précédent ne l'était pas. Cela s'avère utile lorsque le workflow précédent est intentionnellement non privilégié, mais que vous devez effectuer une action privilégiée dans un workflow ultérieur.
Dans cet exemple, un workflow est configuré pour s'exécuter une fois le workflow « Exécuter les tests » distinct terminé.
on:
workflow_run:
workflows: [Run Tests]
types:
- completed
Si vous spécifiez plusieurs workflows
pour l'événement workflow_run
, un seul des workflows doit s'exécuter. Par exemple, un workflow avec le déclencheur suivant s'exécute chaque fois que le workflow « Préproduction » ou le workflow « Lab » se termine.
on:
workflow_run:
workflows: [Staging, Lab]
types:
- completed
Exécution d'un workflow en fonction de la conclusion d'un autre workflow
Une exécution de workflow est déclenchée indépendamment de la conclusion du workflow précédent. Si vous souhaitez exécuter un travail ou une étape en fonction du résultat du workflow déclencheur, vous pouvez utiliser une condition avec la propriété github.event.workflow_run.conclusion
. Par exemple, ce workflow s'exécute chaque fois qu'un workflow nommé « Build » se termine, mais le travail on-success
s'exécute uniquement si le workflow « Build » a réussi, et le travail on-failure
s'exécute uniquement si le workflow « Build » a échoué :
on:
workflow_run:
workflows: [Build]
types: [completed]
jobs:
on-success:
runs-on: ubuntu-latest
if: ${{ github.event.workflow_run.conclusion == 'success' }}
steps:
- run: echo 'The triggering workflow passed'
on-failure:
runs-on: ubuntu-latest
if: ${{ github.event.workflow_run.conclusion == 'failure' }}
steps:
- run: echo 'The triggering workflow failed'
Limitation de votre workflow à exécuter en fonction des branches
Vous pouvez utiliser le filtre branches
ou branches-ignore
pour spécifier les branches sur lesquelles le workflow déclencheur doit s'exécuter afin de déclencher votre workflow. Pour plus d'informations, consultez « Workflow syntax for GitHub Actions ». Par exemple, un workflow avec le déclencheur suivant s'exécute uniquement lorsque le workflow nommé Build
s'exécute sur une branche nommée canary
.
on:
workflow_run:
workflows: [Build]
types: [requested]
branches: [canary]
Utilisation de données à partir du workflow déclencheur
Vous pouvez accéder à la charge utile d'événement workflow_run
qui correspond au workflow ayant déclenché votre workflow. Par exemple, si votre workflow déclencheur génère des artefacts, un workflow déclenché avec l'événement workflow_run
peut accéder à ces artefacts.
Le workflow suivant charge les données en tant qu'artefact. (Dans cet exemple simplifié, les données sont le numéro de la demande de tirage.)
name: Upload data
on:
pull_request:
jobs:
upload:
runs-on: ubuntu-latest
steps:
- name: Save PR number
env:
PR_NUMBER: ${{ github.event.number }}
run: |
mkdir -p ./pr
echo $PR_NUMBER > ./pr/pr_number
- uses: actions/upload-artifact@v3
with:
name: pr_number
path: pr/
Lorsqu'une exécution du workflow ci-dessus se termine, cela déclenche une exécution du workflow suivant. Le workflow suivant utilise le contexte github.event.workflow_run
et l'API REST GitHub Enterprise Server pour télécharger l'artefact chargé par le workflow ci-dessus, décompresse l'artefact téléchargé, puis commente la demande de tirage dont le numéro a été chargé en tant qu'artefact.
name: Use the data
on:
workflow_run:
workflows: [Upload data]
types:
- completed
jobs:
download:
runs-on: ubuntu-latest
steps:
- name: 'Download artifact'
uses: actions/github-script@v6
with:
script: |
let allArtifacts = await github.rest.actions.listWorkflowRunArtifacts({
owner: context.repo.owner,
repo: context.repo.repo,
run_id: context.payload.workflow_run.id,
});
let matchArtifact = allArtifacts.data.artifacts.filter((artifact) => {
return artifact.name == "pr_number"
})[0];
let download = await github.rest.actions.downloadArtifact({
owner: context.repo.owner,
repo: context.repo.repo,
artifact_id: matchArtifact.id,
archive_format: 'zip',
});
let fs = require('fs');
fs.writeFileSync(`${process.env.GITHUB_WORKSPACE}/pr_number.zip`, Buffer.from(download.data));
- name: 'Unzip artifact'
run: unzip pr_number.zip
- name: 'Comment on PR'
uses: actions/github-script@v6
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
script: |
let fs = require('fs');
let issue_number = Number(fs.readFileSync('./pr_number'));
await github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: issue_number,
body: 'Thank you for the PR!'
});