Déclenchement d’un workflow

À propos des déclencheurs de workflow

Les déclencheurs de workflow sont des événements qui entraînent l’exécution d’un workflow. Ces événements peuvent être les suivants :

• Événements qui se produisent dans le dépôt de votre workflow
• Événements qui se produisent en dehors de GitHub Enterprise Cloud et qui déclenchent un événement repository_dispatch sur GitHub Enterprise Cloud
• Heures planifiées
• Manuel

Par exemple, vous pouvez configurer votre workflow pour qu’il s’exécute lorsqu’un push est effectué vers la branche par défaut de votre dépôt, lorsqu’une version est créée ou lorsqu’un problème est ouvert.

Les déclencheurs de workflow sont définis avec la clé on. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».

Les étapes suivantes se produisent pour déclencher une exécution de workflow :

1. Un événement se produit sur votre dépôt. Une référence Git et un SHA de commit sont associés à l’événement.

2. GitHub Enterprise Cloud recherche dans le répertoire .github/workflows à la racine de votre dépôt les fichiers de workflow qui sont présents dans la référence Git ou le SHA de commit associés de l’événement.

3. Une exécution de workflow est déclenchée pour tous les workflows qui ont des valeurs on: correspondant à l’événement de déclenchement. Certains événements nécessitent également que le fichier de workflow soit présent sur la branche par défaut du dépôt pour qu’il s’exécute.

   Chaque exécution de workflow utilise la version du workflow présente dans la référence Git ou le SHA de commit associés de l’événement. Lorsqu’un workflow s’exécute, GitHub Enterprise Cloud définit les variables d’environnement GITHUB_SHA (SHA de commit) et GITHUB_REF (référence Git) dans l’environnement de l’exécuteur. Pour plus d’informations, consultez « Stocker des informations dans des variables ».

Déclenchement d’un workflow à partir d’un workflow

Lorsque vous utilisez le GITHUB_TOKEN du dépôt pour effectuer des tâches, les événements déclenchés par le GITHUB_TOKEN, avec l’exception de workflow_dispatch et de repository_dispatch, ne créent pas de nouvelle exécution de workflow. Cela vous empêche de créer accidentellement des exécutions de workflow récursives. Par exemple, si une exécution de workflow pousse (push) du code à l’aide du GITHUB_TOKEN du dépôt, aucun nouveau workflow ne s’exécute même quand le dépôt contient un workflow configuré pour s’exécuter quand des événements push se produisent. Pour plus d’informations, consultez « Authentification par jeton automatique ».

Si vous souhaitez déclencher un workflow à partir d’une exécution de workflow, vous pouvez utiliser une GitHub App ou un personal access token au lieu de GITHUB_TOKEN pour déclencher des événements qui nécessitent un jeton.

Si vous utilisez une GitHub App, vous devez créer une GitHub App et stocker l’ID d’application et la clé privée en tant que secrets. Pour plus d’informations, consultez « Effectuer des requêtes d’API authentifiées avec une application GitHub dans un workflow GitHub Actions ». Si vous utilisez un personal access token, vous devez créer un personal access token et le stocker en tant que secret. Pour plus d’informations sur la création d’un personal access token, consultez « Gestion de vos jetons d'accès personnels ». Pour plus d’informations sur le stockage de secrets, consultez « Utilisation de secrets dans GitHub Actions ».

Pour réduire vos coûts d’utilisation de GitHub Actions, veillez à ne pas créer d’exécutions de workflow récursives ou involontaires.

Par exemple, le workflow suivant utilise un personal access token (stocké en tant que secret appelé MY_TOKEN) pour ajouter une étiquette à un problème via GitHub CLI. Tous les workflows qui s’exécutent lorsqu’une étiquette est ajoutée s’exécutent une fois cette étape effectuée.

on:
  issues:
    types:
      - opened

jobs:
  label_issue:
    runs-on: ubuntu-latest
    steps:
      - env:
          GH_TOKEN: ${{ secrets.MY_TOKEN }}
          ISSUE_URL: ${{ github.event.issue.html_url }}
        run: |
          gh issue edit $ISSUE_URL --add-label "triage"

À l’inverse, le workflow suivant utilise GITHUB_TOKEN pour ajouter une étiquette à un problème. Il ne déclenche aucun workflow qui s’exécute lorsqu’une étiquette est ajoutée.

on:
  issues:
    types:
      - opened

jobs:
  label_issue:
    runs-on: ubuntu-latest
    steps:
      - env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          ISSUE_URL: ${{ github.event.issue.html_url }}
        run: |
          gh issue edit $ISSUE_URL --add-label "triage"

Utilisation d’événements pour déclencher des workflows

Utilisez la clé on pour spécifier quels événements déclenchent votre workflow. Pour plus d’informations sur les événements que vous pouvez utiliser, consultez « Événements qui déclenchent des flux de travail ».

Utilisation d’un seul événement

Par exemple, un workflow avec la valeur on suivante s’exécute quand une poussée (push) est effectuée dans une branche incluse dans son dépôt :

on: push

Utilisation de plusieurs événements

Vous pouvez spécifier un événement unique ou plusieurs événements. Par exemple, un workflow avec la valeur on suivante s’exécute quand une poussée (push) est effectuée dans une branche du dépôt ou quand quelqu’un duplique (fork) le dépôt :

on: [push, fork]

Si vous spécifiez plusieurs événements, un seul de ces événements a besoin de se produire pour déclencher votre workflow. Si plusieurs événements déclencheurs se produisent pour votre workflow en même temps, plusieurs exécutions de workflow sont déclenchées.

Utilisation de types d’activités et de filtres avec plusieurs événements

Vous pouvez utiliser des types d’activités et des filtres pour contrôler davantage le moment où votre workflow s’exécute. Pour plus d’informations, consultez Utilisation de types d’activités d’événement et Utilisation de filtres. Si vous spécifiez des types d’activités ou des filtres pour un événement et que votre workflow se déclenche sur plusieurs événements, vous devez configurer chaque événement séparément. Vous devez ajouter un signe deux-points (:) à tous les événements, notamment aux événements sans configuration.

Par exemple, un workflow avec la valeur on suivante s’exécute quand :

• Une étiquette est créée.
• Une poussée (push) est effectuée dans la branche main du dépôt.
• Une poussée (push) est effectuée dans une branche compatible avec GitHub Pages.

on:
  label:
    types:
      - created
  push:
    branches:
      - main
  page_build:

Utilisation de types d’activités d’événement

Certains événements ont des types d’activités qui vous donnent davantage de contrôle sur le moment où votre workflow devrait s’exécuter. Utilisez on.<event_name>.types pour définir le type d’activité d’événement qui déclenchera l’exécution d’un workflow.

Par exemple, l’événement issue_comment a les types d’activité created, edited et deleted. Si votre worflow se déclenche sur l’événement label, il s’exécute chaque fois qu’une étiquette est créée, modifiée ou supprimée. Si vous spécifiez le type d’activité created de l’événement label, votre workflow s’exécute quand une étiquette est créée, mais pas quand une étiquette est modifiée ou supprimée.

on:
  label:
    types:
      - created

Si vous spécifiez plusieurs types d’activités, un seul de ceux-ci doit se produire pour déclencher votre workflow. Si plusieurs types d’activité d’événement déclencheur pour votre workflow se produisent simultanément, plusieurs exécutions de workflow seront déclenchées. Par exemple, le workflow suivant se déclenche quand un problème est ouvert ou étiqueté. Si un problème avec deux étiquettes est ouvert, trois exécutions de workflow démarrent : une pour l’événement d’ouverture du problème, et deux pour les deux événements étiquetés du problème.

on:
  issues:
    types:
      - opened
      - labeled

Pour plus d’informations sur chaque événement et leurs types d’activité, consultez « Événements qui déclenchent des flux de travail ».

Utilisation de filtres

Certains événements comportent des filtres qui vous permettent de mieux contrôler le moment où votre workflow devrait s’exécuter.

Par exemple, l’événement push comporte un filtre branches avec lequel votre workflow ne s’exécute que lorsqu’un envoi (push) vers une branche qui correspond au filtre branches se produit, et non lorsque n’importe quel envoi se produit.

on:
  push:
    branches:
      - main
      - 'releases/**'

Utilisation de filtres afin de cibler des branches spécifiques pour les événements de demande de tirage (pull request)

Quand vous utilisez les événements pull_request et pull_request_target vous pouvez configurer un workflow afin qu’il s’exécute uniquement pour les demandes de tirage (pull requests) qui ciblent des branches spécifiques.

Utilisez le filtre branches quand vous souhaitez inclure des modèles de noms de branches, ou quand vous souhaitez à la fois inclure et exclure des modèles de noms de branches. Utilisez le filtre branches-ignore quand vous souhaitez exclure uniquement les modèles de nom de branche. Vous ne pouvez pas utiliser les filtres branches et branches-ignore en même temps pour le même événement dans un workflow.

Si vous définissez à la fois branches/branches-ignore et paths/paths-ignore, le workflow s’exécute uniquement quand les deux filtres sont satisfaits.

Les mots clés branches et branches-ignore acceptent les modèles Glob qui utilisent des caractères tels que *, **, +, ?, ! et certains autres pour correspondre à plusieurs noms de branches. Si un nom contient l’un de ces caractères et si vous souhaitez une correspondance littérale, vous devez utiliser le caractère d’échappement \ avec chacun de ces caractères spéciaux. Pour plus d’informations sur les modèles glob, consultez « Workflow syntax for GitHub Actions ».

Exemple : Inclusion de branches

Les modèles définis dans branches sont évalués par rapport au nom de la référence Git. Par exemple, le workflow suivant s’exécute chaque fois qu’il existe un événement pull_request pour une demande de tirage qui cible :

• Une branche nommée main (refs/heads/main)
• Une branche nommée mona/octocat (refs/heads/mona/octocat)
• Une branche dont le nom commence par releases/, par exemple releases/10 (refs/heads/releases/10)

on:
  pull_request:
    # Sequence of patterns matched against refs/heads
    branches:
      - main
      - 'mona/octocat'
      - 'releases/**'

Vous ne devez pas utiliser le filtrage de chemin d’accès ou de branche pour ignorer les exécutions de workflow si celui-ci doit aboutir avant la fusion. Pour plus d’informations, consultez « Exécutions de workflow ignorées » et « Règles disponibles pour les ensembles de règles ».

Si un workflow est ignoré en raison du filtrage de branche, du filtrage de chemin d’accès ou d’un message de commit, les vérifications associées à ce workflow restent alors à l’état « En attente ». La fusion d’une demande de tirage (pull request) nécessitant la réussite de ces vérifications sera bloquée.

Exemple : Exclusion de branches

Quand un modèle correspond au modèle branches-ignore, le workflow ne s’exécute pas. Les modèles définis dans branches-ignore sont évalués par rapport au nom de la référence Git. Par exemple, le workflow suivant s’exécute chaque fois qu’il existe un événement pull_request, sauf si la demande de tirage cible :

• Une branche nommée mona/octocat (refs/heads/mona/octocat)
• Une branche dont le nom correspond à releases/**-alpha, par exemple releases/beta/3-alpha (refs/heads/releases/beta/3-alpha)

on:
  pull_request:
    # Sequence of patterns matched against refs/heads
    branches-ignore:
      - 'mona/octocat'
      - 'releases/**-alpha'

Exemple : Inclusion et exclusion de branches

Vous ne pouvez pas utiliser branches et branches-ignore pour filtrer le même événement dans un seul workflow. Si vous souhaitez à la fois inclure et exclure des modèles de branche pour un seul événement, utilisez le filtre branches avec le caractère ! pour indiquer les branches à exclure.

Si vous définissez une branche avec le caractère !, vous devez également définir au moins une branche sans le caractère !. Si vous souhaitez uniquement exclure des branches, utilisez branches-ignore à la place.

L’ordre dans lequel vous définissez les modèles est important.

• Un modèle de correspondance négative (préfixé avec !) après une correspondance positive exclut la référence Git.
• Un modèle de correspondance positive après une correspondance négative inclut à nouveau la référence Git.

Le workflow suivant s’exécute sur les événements pull_request pour les demandes de tirage qui ciblent releases/10 ou releases/beta/mona, mais pas pour les demandes de tirage qui ciblent releases/10-alpha ou releases/beta/3-alpha, car le modèle négatif !releases/**-alpha suit le modèle positif.

on:
  pull_request:
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

Utilisation de filtres afin de cibler des branches ou des étiquettes spécifiques pour les événements de transmission de type push

Lorsque vous utilisez l’événement push, vous pouvez configurer un workflow pour qu’il s’exécute sur des branches ou des étiquettes spécifiques.

Utilisez le filtre branches lorsque vous souhaitez inclure des modèles de noms de branche ou lorsque vous souhaitez inclure et exclure des modèles de noms de branche. Utilisez le filtre branches-ignore quand vous souhaitez exclure uniquement les modèles de nom de branche. Vous ne pouvez pas utiliser les filtres branches et branches-ignore en même temps pour le même événement dans un workflow.

Utilisez le filtre tags lorsque vous souhaitez inclure des modèles de nom d’étiquette ou lorsque vous souhaitez inclure et exclure des modèles de noms d’étiquette. Utilisez le filtre tags-ignore lorsque vous souhaitez exclure uniquement les modèles de nom d’étiquette. Vous ne pouvez pas utiliser les filtres tags et tags-ignore en même temps pour le même événement dans un workflow.

Si vous définissez uniquement tags/tags-ignore ou uniquement branches/branches-ignore, le flux de travail ne s’exécutera pas pour les événements affectant la référence Git non définie. Si vous définissez ni tags/tags-ignore ou branches/branches-ignore, le flux de travail sera exécuté pour les événements affectant les branches ou les étiquettes. Si vous définissez à la fois branches/branches-ignore et paths/paths-ignore, le workflow s’exécute uniquement quand les deux filtres sont satisfaits.

Les mots clés branches, branches-ignore, tags et tags-ignore acceptent des modèles Glob qui utilisent des caractères tels que *, **, +, ?, ! et d’autres pour correspondre à plus d’un nom de branche ou d’étiquette Si un nom contient l’un de ces caractères et que vous souhaitez une correspondance littérale, vous devez échapper chacun de ces caractères spéciaux avec \. Pour plus d’informations sur les modèles glob, consultez « Workflow syntax for GitHub Actions ».

Exemple : Inclure des branches et des étiquettes

Les modèles définis dans branches et tags sont évalués par rapport au nom de la référence Git. Par exemple, le workflow suivant s’exécuterait chaque fois qu’il existe un événement push pour :

• Une branche nommée main (refs/heads/main)
• Une branche nommée mona/octocat (refs/heads/mona/octocat)
• Une branche dont le nom commence par releases/, par exemple releases/10 (refs/heads/releases/10)
• Une étiquette nommée v2 (refs/tags/v2)
• Une étiquette dont le nom commence par v1., comme v1.9.1 (refs/tags/v1.9.1)

on:
  push:
    # Sequence of patterns matched against refs/heads
    branches:
      - main
      - 'mona/octocat'
      - 'releases/**'
    # Sequence of patterns matched against refs/tags
    tags:
      - v2
      - v1.*

Exemple : Exclusion de branches et d’étiquettes

Lorsqu’un modèle correspond au modèle branches-ignore ou tags-ignore, le workflow n’est pas exécuté. Les modèles définis dans branches et tags sont évalués par rapport au nom de la référence Git. Par exemple, le workflow suivant s’exécuterait chaque fois qu’il existe un événement push, sauf si l’événement push concerne :

• Une branche nommée mona/octocat (refs/heads/mona/octocat)
• Une branche dont le nom correspond à releases/**-alpha, par exemple releases/beta/3-alpha (refs/heads/releases/beta/3-alpha)
• Une étiquette nommée v2 (refs/tags/v2)
• Une étiquette dont le nom commence par v1., comme v1.9 (refs/tags/v1.9)

on:
  push:
    # Sequence of patterns matched against refs/heads
    branches-ignore:
      - 'mona/octocat'
      - 'releases/**-alpha'
    # Sequence of patterns matched against refs/tags
    tags-ignore:
      - v2
      - v1.*

Exemple : Inclure et exclure des branches et des étiquettes

Vous ne pouvez pas utiliser branches et branches-ignore pour filtrer le même événement dans un même workflow. De même, vous ne pouvez pas utiliser tags et tags-ignore pour filtrer le même événement dans un même workflow. Si vous souhaitez inclure et exclure des modèles de branche ou d’étiquette pour un seul événement, utilisez le filtre branches ou tags avec le caractère ! pour indiquer quelles branches ou étiquettes doivent être exclues.

Si vous définissez une branche avec le caractère !, vous devez également définir au moins une branche sans caractère !. Si vous souhaitez uniquement exclure des branches, utilisez branches-ignore à la place. De même, si vous définissez une étiquette avec le caractère !, vous devez également définir au moins une étiquette sans caractère !. Si vous souhaitez uniquement exclure des étiquettes, utilisez tags-ignore à la place.

L’ordre dans lequel vous définissez les modèles est important.

• Un modèle de correspondance négative (préfixé avec !) après une correspondance positive exclut la référence Git.
• Un modèle de correspondance positive après une correspondance négative inclut à nouveau la référence Git.

Le workflow suivant s’exécute sur les envois push vers releases/10 ou releases/beta/mona, mais pas sur releases/10-alpha ou releases/beta/3-alpha parce que le modèle négatif !releases/**-alpha fait suite au modèle positif.

on:
  push:
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

Utilisation de filtres afin de cibler des chemins spécifiques pour les événements de demande de tirage (pull request) ou de transmission de type push

Lorsque vous utilisez les événements push et pull_request événements, vous pouvez configurer un workflow pour qu’il s’exécute en fonction des chemins d’accès aux fichiers qui ont changé. Les filtres de chemin d’accès ne sont pas évalués pour les envois (push) d’étiquettes.

Utilisez le filtre paths lorsque vous souhaitez inclure des modèles de chemins d’accès aux fichiers, ou lorsque vous souhaitez à la fois inclure et exclure des modèles de modèles de chemins d’accès aux fichiers. Utilisez le filtre paths-ignore lorsque vous souhaitez uniquement exclure modèles de chemins d’accès aux fichiers. Vous ne pouvez pas utiliser les filtres paths et paths-ignore en même temps pour le même événement dans un workflow. Si vous souhaitez inclure et exclure des modèles de chemin d’accès pour un seul événement, utilisez le filtre paths avec en préfixe le caractère ! pour indiquer les chemins d’accès à exclure.

Si vous définissez à la fois branches/branches-ignore et paths/paths-ignore, le workflow s’exécute uniquement quand les deux filtres sont satisfaits.

Les mots clés paths et paths-ignore acceptent des modèles globaux qui utilisent les caractères génériques * et ** pour faire correspondre plusieurs noms de chemin d’accès. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».

Exemple : Inclusion de chemins d’accès

Si au moins un chemin d’accès correspond à un modèle dans le filtre paths, le workflow s’exécute. Par exemple, le workflow suivant s’exécuterait chaque fois que vous envoyez (push) un fichier JavaScript (.js).

on:
  push:
    paths:
      - '**.js'

Vous ne devez pas utiliser le filtrage de chemin d’accès ou de branche pour ignorer les exécutions de workflow si celui-ci doit aboutir avant la fusion. Pour plus d’informations, consultez « Exécutions de workflow ignorées » et « Règles disponibles pour les ensembles de règles ».

Si un workflow est ignoré en raison du filtrage de chemin d’accès, du filtrage de branche ou d’un message de commit, les vérifications associées à ce workflow restent alors à l’état « En attente ». La fusion d’une demande de tirage (pull request) nécessitant la réussite de ces vérifications sera bloquée.

Exemple : Exclusion de chemins d’accès

Lorsque tous les noms de chemin d’accès correspondent à des modèles dans paths-ignore, le workflow ne s’exécute pas. Si des noms de chemin d’accès ne correspondent pas à des modèles dans paths-ignore, même si certains noms de chemin d’accès correspondent aux modèles, le workflow s’exécute.

Un workflow avec le filtre de chemin d’accès suivant s’exécute uniquement sur des événements push qui incluent au moins un fichier en dehors du répertoire docs à la racine du dépôt.

on:
  push:
    paths-ignore:
      - 'docs/**'

Exemple : Inclusion et exclusion de chemins d’accès

Vous ne pouvez pas utiliser paths et paths-ignore pour filtrer le même événement dans un seul workflow. Si vous souhaitez inclure et exclure des modèles de chemin d’accès pour un seul événement, utilisez le filtre paths avec en préfixe le caractère ! pour indiquer les chemins d’accès à exclure.

Si vous définissez un chemin d’accès avec le caractère !, vous devez également définir au moins un chemin d’accès sans caractère !. Si vous souhaitez uniquement exclure des chemins d’accès, utilisez plutôt paths-ignore.

L’ordre dans lequel vous définissez les modèles paths est important :

• Un modèle négatif de correspondance (préfixé avec !) après une correspondance positive exclut le chemin d’accès.
• Un modèle positif de correspondance après une correspondance négative inclut à nouveau le chemin d’accès.

Cet exemple s’exécute à chaque fois que l’événement push inclut un fichier dans le répertoire sub-project ou ses sous-répertoires, sauf si le fichier se trouve dans le répertoire sub-project/docs. Par exemple, un envoi (push) qui change sub-project/index.js ou sub-project/src/index.js déclenche l’exécution d’un workflow, au contraire d’un envoi (push) changeant uniquement sub-project/docs/readme.md.

on:
  push:
    paths:
      - 'sub-project/**'
      - '!sub-project/docs/**'

Comparaisons de différences Git

Le filtre détermine si un workflow doit s’exécuter en évaluant les fichiers modifiés et en les exécutant sur la liste paths-ignore ou paths. S’il n’y a pas de fichier modifié, le workflow ne s’exécute pas.

GitHub génère la liste des fichiers modifiés à l’aide de différences de deux points pour les envois (push) et de différences de trois points pour les demandes de tirage :

• Demandes de tirage : les différences de trois points sont une comparaison entre la version la plus récente de la branche de rubrique, et la validation dans laquelle la branche de rubrique a été synchronisée pour la dernière fois avec la branche de base.
• Envois (push) à des branches existantes : une différence de deux points compare directement les SHA principal et de base.
• Envois (push) à nouvelles branches : une différence de deux points par rapport au parent de l’élément ancêtre de la validation la plus profonde envoyées (push).

Les différences sont limitées à 300 fichiers. S’il y a des fichiers modifiés qui ne sont pas mis en correspondance dans les 300 premiers fichiers retournés par le filtre, le workflow n’est pas exécuté. Il se peut que vous deviez créer des filtres plus spécifiques afin que le workflow s’exécute automatiquement.

Pour plus d’informations, consultez « À propos de la comparaison des branches dans les demandes de tirage ».

Utilisation de filtres afin de cibler des branches spécifiques pour les événements d’exécution de workflow

Lorsque vous utilisez l’événement workflow_run, vous pouvez spécifier les branches sur lesquelles le workflow déclencheur doit s’exécuter afin de déclencher votre workflow.

Les filtres branches et branches-ignore acceptent les modèles Glob qui utilisent des caractères tels que *, **, +, ?, ! et certains autres pour correspondre à plusieurs noms de branches. Si un nom contient l’un de ces caractères et que vous souhaitez une correspondance littérale, vous devez échapper chacun de ces caractères spéciaux avec \. Pour plus d’informations sur les modèles glob, 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 dont le nom commence par releases/ :

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**'

Un workflow avec le déclencheur suivant s’exécute uniquement lorsque le workflow nommé Build s’exécute sur une branche qui n’est pas nommée canary :

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches-ignore:
      - "canary"

Vous ne pouvez pas utiliser les filtres branches et branches-ignore en même temps pour le même événement dans un workflow. Si vous souhaitez à la fois inclure et exclure des modèles de branche pour un seul événement, utilisez le filtre branches avec le caractère ! pour indiquer les branches à exclure.

L’ordre dans lequel vous définissez les modèles est important.

• Un modèle négatif de correspondance (préfixé avec !) après une correspondance positive exclut la branche.
• Un modèle positif de correspondance après une correspondance négative inclut à nouveau la branche.

Par exemple, un workflow avec le déclencheur suivant s’exécute lorsque le workflow nommé Build s’exécute sur une branche nommée releases/10 ou releases/beta/mona, mais pas releases/10-alpha, releases/beta/3-alpha ni main.

on:
  workflow_run:
    workflows: ["Build"]
    types: [requested]
    branches:
      - 'releases/**'
      - '!releases/**-alpha'

Définition d’entrées pour les workflows déclenchés manuellement

Quand vous utilisez l’événement workflow_dispatch, vous pouvez éventuellement spécifier des entrées qui sont passées au workflow.

Ce déclencheur reçoit uniquement les événements lorsque le fichier de flux de travail se trouve sur la branche par défaut. Le workflow déclenché reçoit les entrées dans le contexte inputs. Pour plus d’informations, consultez « Contextes ».

on:
  workflow_dispatch:
    inputs:
      logLevel:
        description: 'Log level'
        required: true
        default: 'warning'
        type: choice
        options:
          - info
          - warning
          - debug
      print_tags:
        description: 'True to print to STDOUT'
        required: true
        type: boolean
      tags:
        description: 'Test scenario tags'
        required: true
        type: string
      environment:
        description: 'Environment to run tests against'
        type: environment
        required: true

jobs:
  print-tag:
    runs-on: ubuntu-latest
    if:  ${{ inputs.print_tags }} 
    steps:
      - name: Print the input tag to STDOUT
        run: echo  The tags are ${{ inputs.tags }} 

Définition d’entrées, de sorties et de secrets pour les workflows réutilisables

Vous pouvez définir des entrées et des secrets qu’un workflow réutilisable doit recevoir d’un workflow appelant. Vous pouvez également spécifier des sorties qu’un workflow réutilisable met à la disposition d’un workflow appelant. Pour plus d’informations, consultez « Réutilisation des workflows ».

Utilisation des informations sur l’événement

Des informations sur l’événement qui a déclenché une exécution de workflow sont disponibles dans le contexte github.event. Les propriétés du contexte github.event dépendent du type d’événement qui a déclenché le workflow. Par exemple, un workflow déclenché lorsqu’un problème est étiqueté aurait des informations concernant le problème et l’étiquette.

Affichage de toutes les propriétés d’un événement

Reportez-vous à la documentation des événements de webhook pour connaître les propriétés courantes et obtenir des exemples de charges utiles. Pour plus d’informations, consultez « Événements et charges utiles du webhook ».

Vous pouvez également imprimer l’intégralité du contexte github.event pour voir quelles propriétés sont disponibles pour l’événement qui a déclenché votre workflow :

jobs:
  print_context:
    runs-on: ubuntu-latest
    steps:
      - env:
          EVENT_CONTEXT: ${{ toJSON(github.event) }}
        run: |
          echo $EVENT_CONTEXT

Accès et utilisation de propriétés d’événement

Vous pouvez utiliser le contexte github.event dans votre workflow. Par exemple, le workflow suivant s’exécute lorsqu’une demande de tirage qui change package*.json, .github/CODEOWNERS ou .github/workflows/** est ouverte. Si l’auteur de la demande de tirage (github.event.pull_request.user.login) n’est pas octobot ou dependabot[bot], le workflow utilise l’GitHub CLI pour étiqueter et commenter la demande de tirage (github.event.pull_request.number).

on:
  pull_request:
    types:
      - opened
    paths:
      - '.github/workflows/**'
      - '.github/CODEOWNERS'
      - 'package*.json'

jobs:
  triage:
    if: >-
      github.event.pull_request.user.login != 'octobot' &&
      github.event.pull_request.user.login != 'dependabot[bot]'
    runs-on: ubuntu-latest
    steps:
      - name: "Comment about changes we can't accept"
        env:
          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          PR: ${{ github.event.pull_request.html_url }}
        run: |
          gh pr edit $PR --add-label 'invalid'
          gh pr comment $PR --body 'It looks like you edited `package*.json`, `.github/CODEOWNERS`, or `.github/workflows/**`. We do not allow contributions to these files. Please review our [contributing guidelines](https://github.com/octo-org/octo-repo/blob/main/CONTRIBUTING.md) for what contributions are accepted.'

Pour plus d’informations sur les contextes, consultez « Accès à des informations contextuelles sur l’exécution d’un workflow ». Pour plus d’informations sur les charges utiles d’événement, consultez « Événements et charges utiles du webhook ».

Contrôle supplémentaire de l’exécution de votre workflow

Si vous souhaitez un contrôle plus précis que ne le permettent les événements, les types d’activité d’événement ou les filtres d’événement, vous pouvez utiliser des conditions et des environnements pour contrôler l’exécution de travaux ou d’étapes spécifiques de votre workflow.

Utilisation de conditions

Vous pouvez utiliser des conditions pour contrôler davantage si des travaux ou des étapes de votre workflow s’exécuteront.

Exemple utilisant une valeur dans la charge utile de l’événement

Par exemple, si vous souhaitez que le workflow s’exécute lorsqu’une étiquette spécifique est ajoutée à un problème, vous pouvez effectuer le déclenchement sur le type d’activité d’événement issues labeled et utiliser une condition pour vérifier quelle étiquette a déclenché le workflow. Le workflow suivant s’exécute quand une étiquette est ajoutée à un problème dans le dépôt du workflow, mais le travail run_if_label_matches s’exécute uniquement si l’étiquette est nommée bug.

on:
  issues:
    types:
      - labeled

jobs:
  run_if_label_matches:
    if: github.event.label.name == 'bug'
    runs-on: ubuntu-latest
    steps:
      - run: echo 'The label was bug'

Exemple utilisant un type d’événement

Par exemple, si vous souhaitez exécuter différents travaux ou différentes étapes en fonction de l’événement déclenché par le workflow, vous pouvez utiliser une condition pour vérifier s’il existe un type d’événement spécifique dans le contexte de l’événement. Le workflow suivant s’exécute chaque fois qu’un problème ou une demande de tirage est fermé. Si le workflow a été exécuté parce qu’un problème a été fermé, le contexte github.event contient une valeur pour issue, mais pas pour pull_request. Par conséquent, l’étape if_issue s’exécute, mais pas l’étape if_pr. À l’inverse, si le workflow a été exécuté parce qu’une demande de tirage a été fermée, l’étape if_pr s’exécute, mais pas l’étape if_issue.

on:
  issues:
    types:
      - closed
  pull_request:
    types:
      - closed

jobs:
  state_event_type:
    runs-on: ubuntu-latest
    steps:
    - name: if_issue
      if: github.event.issue
      run: |
        echo An issue was closed
    - name: if_pr
      if: github.event.pull_request
      run: |
        echo A pull request was closed

Pour en savoir plus sur la nature des informations disponibles dans le contexte d’événement, consultez « Utilisation des informations sur l’événement ». Pour plus d’informations sur l’utilisation de conditions, consultez « Évaluer les expressions dans les workflows et les actions ».

Utilisation d’environnements pour déclencher manuellement des travaux de workflow

Si vous souhaitez déclencher manuellement un travail spécifique d’un workflow, vous pouvez utiliser un environnement qui nécessite l’approbation d’une équipe ou d’un utilisateur spécifique. Tout d’abord, configurez un environnement avec les réviseurs obligatoires. Pour plus d’informations, consultez « Gestion des environnements pour le déploiement ». Ensuite, référencez le nom de l’environnement dans un travail de votre workflow à l’aide de la clé environment:. Tout travail référençant l’environnement ne s’exécute qu’une fois qu’un réviseur au moins a approuvé le travail.

Par exemple, le workflow suivant s’exécute chaque fois qu’il y a une transmission de type push dans la branche principale. Le travail build s’exécute toujours. Le travail publish s’exécute uniquement une fois que le travail build s’est terminé correctement (en raison de needs: [build]) et que toutes les règles (y compris les réviseurs obligatoires) définies pour l’environnement appelé production sont respectées ( en raison de environment: production).

on:
  push:
    branches:
      - main

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: build
        echo 'building'

  publish:
    needs: [build]
    runs-on: ubuntu-latest
    environment: production
    steps:
      - name: publish
        echo 'publishing'

Événements disponibles

Pour obtenir la liste complète des événements disponibles, consultez « Événements qui déclenchent des flux de travail ».