Événements qui déclenchent des flux de travail

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

branch_protection_rule

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

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, veuillez consulter la section 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

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, veuillez consulter la section Utilisation de l’API REST pour interagir avec des vérifications. Pour plus d’informations sur les API de suite 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

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

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

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

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

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

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

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

Par exemple, vous pouvez exécuter un workflow lorsque l’événement fork se produit.

on:
  fork

gollum

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

image_version

Exécute votre flux de travail lorsqu’une nouvelle version d’une image spécifiée devient disponible pour une utilisation. Cet événement est généralement déclenché après la création d’une version d’image réussie, ce qui vous permet d’automatiser des actions telles que le déploiement ou les notifications en réponse aux nouvelles versions d’image.

Cet événement prend en charge les modèles globaux pour les noms d'images et les versions. L’exemple ci-dessous se déclenche lorsqu’une nouvelle version d’image correspond à l’une des combinaisons de noms et de versions spécifiés. Par exemple, ["MyNewImage", 1.0.0], , ["MyNewImage", 2.53.0], ["MyOtherImage", 1.0.0]et ["MyOtherImage", 2.0.0].

on:
  image_version:
    names:
    - "MyNewImage"
    - "MyOtherImage"
    versions:
    - 1.*
    - 2.*

issue_comment

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

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 d'émission, 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

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

          Plusieurs types d’activités déclenchent cet événement. Bien que seul le `checks_requested` type d’activité soit pris en charge, la spécification du type d’activité conserve votre flux de travail spécifique si d’autres types d’activité sont ajoutés à l’avenir. Pour plus d’informations sur chaque type d’activité, consultez [AUTOTITLE](/webhooks-and-events/webhooks/webhook-events-and-payloads#merge_group). 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 « [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes) ».

• 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énement merge_group est distinct des événements pull_request et push.

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 pull request 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

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

Exécute votre workflow lorsqu’une personne pousse des modifications vers une branche qui est la source de publication de GitHub Pages, si GitHub Pages est activé pour le dépôt. Pour plus d’informations sur les GitHub Pages sources de publication, 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

public

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

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 pull requests.

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. Pour plus d’informations sur les branches de fusion, consultez À propos des demandes de tirage (pull requests).

Impact de la branche de fusion sur votre flux de travail

Pour les pull requests ouvertes pouvant être fusionnées, les workflows déclenchés par l’événement pull_request définissent GITHUB_REF sur la branche de fusion. Étant donné que actions/checkout utilise GITHUB_REF par défaut, il extrait la branche de fusion. Vos tests CI s’exécutent sur le résultat fusionné, et non uniquement sur la branche source :

•           `GITHUB_REF` est défini sur `refs/pull/PULL_REQUEST_NUMBER/merge`
  

•           `GITHUB_SHA` correspond au SHA du commit de fusion sur la branche de fusion.
  

Pour tester uniquement les validations de la branche principale sans simuler de fusion, consultez la branche principale à l’aide de github.event.pull_request.head.sha dans votre flux de travail.

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 « Syntaxe de flux de travail pour 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/**'

          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 flux de travaux suivant s’exécute uniquement lorsqu’une demande de fusion incluant une modification d’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 « Syntaxe de flux de travail pour 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'

          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 flux de travaux suivant s’exécute uniquement lorsqu’une demande de fusion incluant une modification d’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 « Utiliser GITHUB_TOKEN pour l’authentification dans les flux de travail ».

É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 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é.

Quand un contributeur envoie pour la première fois une demande de tirage à un dépôt public, il se peut qu’un responsable de maintenance disposant d’un accès en écriture doive approuver les flux de travail en cours d’exécution sur la demande de tirage. Pour plus d’informations, consultez « Approbation d’exécutions de workflow à partir de duplications ».

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 référentiel.

          `pull_request_comment` (utilisez `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

          Plusieurs types d’activités déclenchent cet événement. Pour plus d’informations sur chaque type d’activité, consultez [AUTOTITLE](/webhooks-and-events/webhooks/webhook-events-and-payloads#pull_request_review). 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 « [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes) ».

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 d'examen des demandes de tirage, consultez Objets dans la documentation sur l’API GraphQL ou Points de terminaison d’API REST pour les pull requests.

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 « Utiliser GITHUB_TOKEN pour l’authentification dans les flux de travail ».

É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 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é.

Quand un contributeur envoie pour la première fois une demande de tirage à un dépôt public, il se peut qu’un responsable de maintenance disposant d’un accès en écriture doive approuver les flux de travail en cours d’exécution sur la demande de tirage. Pour plus d’informations, consultez « Approbation d’exécutions de workflow à partir de duplications ».

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 référentiel.

pull_request_review_comment

          Plusieurs types d’activités déclenchent cet événement. Pour plus d’informations sur chaque type d’activité, consultez [AUTOTITLE](/webhooks-and-events/webhooks/webhook-events-and-payloads#pull_request_review_comment). 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 « [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes) ».

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 obtenir des informations sur les API de commentaires de révision des demandes de tirage, consultez Objets dans la documentation sur l’API GraphQL ou Points de terminaison d’API REST pour les pull requests.

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 « Utiliser GITHUB_TOKEN pour l’authentification dans les flux de travail ».

É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 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é.

Quand un contributeur envoie pour la première fois une demande de tirage à un dépôt public, il se peut qu’un responsable de maintenance disposant d’un accès en écriture doive approuver les flux de travail en cours d’exécution sur la demande de tirage. Pour plus d’informations, consultez « Approbation d’exécutions de workflow à partir de duplications ».

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 référentiel.

pull_request_target

          Plusieurs types d’activités déclenchent cet événement. Pour plus d’informations sur chaque type d’activité, consultez [AUTOTITLE](/webhooks-and-events/webhooks/webhook-events-and-payloads#pull_request). 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 « [AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#onevent_nametypes) ».

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 de la branche par défaut du dépôt de base, plutôt que dans le contexte du commit de fusion, comme c’est le cas pour 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.

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 « Syntaxe de flux de travail pour 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/**'

          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 flux de travaux suivant s’exécute uniquement lorsqu’une demande de fusion incluant une modification d’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 « Syntaxe de flux de travail pour 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'

          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 flux de travaux suivant s’exécute uniquement lorsqu’une demande de fusion incluant une modification d’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

Exécute votre workflow lorsque vous validez une modification 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

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 « Syntaxe de flux de travail pour 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/**'

          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 flux de travail suivant s’exécute uniquement lorsqu’un push qui inclut une modification d’un fichier JavaScript (`.js`) est effectué 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 « Syntaxe de flux de travail pour 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 « Syntaxe de flux de travail pour 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'

registry_package

jobs:
    job_name:
        if: $true

Exécute votre flux de travail lorsque l’activité liée à GitHub Packages se produit dans votre référentiel. Pour plus d’informations, consultez GitHub Packages la documentation.

Par exemple, vous pouvez exécuter un workflow quand une nouvelle version de package est published.

on:
  registry_package:
    types: [published]

release

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

Vous pouvez utiliser l’API GitHub pour déclencher un événement webhook appelé repository_dispatch lorsque vous souhaitez déclencher un flux de travail pour l’activité qui se produit en dehors de GitHub. 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]

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

schedule

L’événement schedule vous permet de déclencher un workflow à une heure planifiée.

          **Exemple :**

 on:
   schedule:
     - cron: "15 4,5 * * *"

Utilisez la syntaxe cron POSIX pour planifier l’exécution des flux de travail à des moments spécifiques. Par défaut, les flux de travail planifiés s’exécutent au format UTC. Vous pouvez éventuellement spécifier un fuseau horaire à l’aide d’une chaîne de fuseau horaire IANA pour la planification prenant en charge le fuseau horaire. Les flux de travail planifiés s’exécutent sur le dernier commit de la branche par défaut. L’intervalle le plus court auquel vous pouvez exécuter des workflows planifiés est une fois toutes les 5 minutes.

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 :

          `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 2ème et à la 10ème minute de chaque 4ème et 5ème heure de la journée. | | - | Plage de valeurs | 30 4-6 * * * s'exécute à la 30e minute des 4e, 5e et 6e heures. | | / | Valeurs d'étape | 20/15 * * * * s'exécute toutes les 15 minutes de la minute 20 à 59 (minutes 20, 35 et 50). |

Cet exemple déclenche l’exécution du flux de travail à 5h30 dans le fuseau horaire de New York, du lundi au vendredi :

on:
  schedule:
    - cron: '30 5 * * 1-5'
      timezone: "America/New_York"

Un seul workflow peut être déclenché par plusieurs événements schedule. Accédez à l’événement schedule qui a déclenché le flux de travail via le contexte github.event.schedule. Dans cet exemple, le flux de travail est déclenché à 5h30 UTC tous les jours du lundi au jeudi, et à 17h30 UTC les mardis et jeudis, mais l’étape Not on Monday or Wednesday est ignorée les lundis et mercredis.

on:
  schedule:
    - cron: '30 5 * * 1,3'
    - cron: '30 5,17 * * 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"

          GitHub Actions ne prend pas en charge la syntaxe non standard `@yearly`, `@monthly`, `@weekly`, `@daily`, `@hourly` et `@reboot`.

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.

          `actor` pour les workflows planifiés

Certains événements du référentiel modifient le actor associé au workflow. Par exemple, un utilisateur qui modifie la branche par défaut du référentiel, ce qui modifie la branche sur laquelle s'exécutent les workflows planifiés, devient actor pour ces workflows planifiés.

Pour un workflow planifié désactivé, si un utilisateur disposant des autorisations write sur le référentiel effectue un commit qui modifie le calendrier cron du workflow, celui-ci sera réactivé et cet utilisateur deviendra le actor associé à toutes les exécutions du workflow.

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

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 de statut de validation, 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

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 la mise en favori.

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

          `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 [AUTOTITLE](/actions/using-workflows/reusing-workflows).

L’exemple ci-dessous exécute le workflow uniquement lorsqu’il est appelé à partir d’un autre workflow :

on: workflow_call

workflow_dispatch

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 flux de travail à l’aide de l’API GitHub , GitHub CLIou de l’interface GitHub utilisateur. 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 « Référence des contextes ».

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 flux de travail à partir d’un script, ou à l'aide de GitHub CLI. Voici un exemple :

gh workflow run run-tests.yml -f logLevel=warning -f tags=false -f environment=staging

Pour plus d’informations, consultez les GitHub CLI informations dans Exécution manuelle d’un workflow.

workflow_run

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 « Syntaxe de flux de travail pour 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@v4
        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 pour télécharger l’artefact chargé par le workflow ci-dessus, décompresse l’artefact téléchargé, puis commente la pull request 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@v8
        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',
            });
            const fs = require('fs');
            const path = require('path');
            const temp = '${{ runner.temp }}/artifacts';
            if (!fs.existsSync(temp)){
              fs.mkdirSync(temp);
            }
            fs.writeFileSync(path.join(temp, 'pr_number.zip'), Buffer.from(download.data));

      - name: 'Unzip artifact'
        run: unzip "${{ runner.temp }}/artifacts/pr_number.zip" -d "${{ runner.temp }}/artifacts"

      - name: 'Comment on PR'
        uses: actions/github-script@v8
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const fs = require('fs');
            const path = require('path');
            const temp = '${{ runner.temp }}/artifacts';
            const issue_number = Number(fs.readFileSync(path.join(temp, '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!'
            });