Remarque : Les exécuteurs hébergés sur GitHub ne sont pas pris en charge sur GitHub Enterprise Server. Vous pouvez voir plus d’informations sur le support futur planifié dans la GitHub public roadmap.
À 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 Server et qui déclenchent un événement
repository_dispatch
sur GitHub Enterprise Server - 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 :
-
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.
-
GitHub Enterprise Server 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. -
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 Server définit les variables d’environnement
GITHUB_SHA
(SHA de commit) etGITHUB_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 exemplereleases/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 exemplereleases/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 workflow ne s’exécutera pas pour les événements affectant la référence Git non définie. Si vous ne définissez ni tags
/tags-ignore
ni branches
/branches-ignore
, le workflow s’exécutera 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 exemplereleases/10
(refs/heads/releases/10
) - Une étiquette nommée
v2
(refs/tags/v2
) - Une étiquette dont le nom commence par
v1.
, commev1.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 exemplereleases/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.
, commev1.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.
Note
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.
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
Note
Si vous envoyez plus de 1 000 validations ou si GitHub ne génère pas la différence en raison d’un délai d’expiration, le workflow s’exécute toujours.
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 ».
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.
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'
Les environnements, les secrets d’environnement et les règles de protection de déploiement sont disponibles dans les référentiels publics pour tous les plans GitHub actuels. Ils ne sont pas disponibles sur des plans hérités, tels que Bronze, Argent ou Or. Pour accéder aux environnements, secrets d’environnement et branches de déploiement dans des dépôts privés ou internes, vous devez utiliser GitHub Pro, GitHub Team ou GitHub Enterprise.
Événements disponibles
Pour obtenir la liste complète des événements disponibles, consultez « Événements qui déclenchent des flux de travail ».