# Déclenchement d’un workflow Comment déclencher GitHub Actions automatiquement des flux de travail ## Prérequis Pour en savoir plus sur les flux de travail et le déclenchement de flux de travail, consultez [Flux de travail](/fr/actions/concepts/workflows-and-actions/workflows). ## 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` ne créent pas de nouvelle exécution de workflow, à l’exception des cas suivants : * `workflow_dispatch` et `repository_dispatch` les événements créent toujours des exécutions de flux de travail. * `pull_request` événements avec les types d’activité `opened`, `synchronize` ou `reopened` : lorsqu’un flux de travail utilisant `GITHUB_TOKEN` crée ou met à jour une pull request, l’événement `pull_request` qui en résulte crée des exécutions de flux de travail à l’état **approval-required**. La pull request affiche une bannière dans l’encadré de fusion, et un utilisateur disposant d’un accès en écriture au dépôt peut lancer les exécutions en sélectionnant **Approuver les workflows à exécuter**. D’autres types d’activité `pull_request` (tels que `labeled`, `edited`ou `closed`) ne créent pas d’exécutions de flux de travail. Cela empêche les exécutions récursives de workflows tout en permettant aux workflows d’intégration continue de s’exécuter sur des pull requests créées automatiquement. Pour plus d’informations sur l’approbation des exécutions de flux de travail, consultez [Approbation d’exécutions de workflow à partir de duplications](/fr/actions/how-tos/manage-workflow-runs/approve-runs-from-forks). Pour tous les autres événements, ce comportement vous empêche de créer accidentellement des exécutions de flux de travail récursives. Par exemple, si une exécution de workflow pousse du code avec le `GITHUB_TOKEN` du dépôt, aucun nouveau workflow ne sera exécuté 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 [Utiliser GITHUB\_TOKEN pour l’authentification dans les flux de travail](/fr/actions/tutorials/authenticate-with-github_token). Si vous souhaitez vraiment déclencher un flux de travail depuis l’exécution d’un flux de travail, vous pouvez utiliser un GitHub App jeton d’accès d’installation ou un personal access token au lieu de `GITHUB_TOKEN` pour déclencher des événements nécessitant un jeton. L’utilisation de l’une de ces alternatives permet également l’exécution automatique des workflows `pull_request` (sans la demande d’approbation décrite ci-dessus) lorsque la pull request est créée ou mise à jour par un processus automatisé. Si vous utilisez un GitHub App, vous devrez créer un GitHub App et enregistrer 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 flux de travail GitHub Actions](/fr/apps/creating-github-apps/authenticating-with-a-github-app/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow) ». Si vous utilisez un personal access token, vous devez créer un personal access token fichier 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](/fr/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens). Pour plus d’informations sur le stockage de secrets, consultez « [Utilisation de secrets dans GitHub Actions](/fr/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets) ». Pour réduire vos GitHub Actions coûts d’utilisation, veillez à ne pas créer d’exécutions de flux de travail récursives ou involontaires. Par exemple, le flux de travail 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. ```yaml 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. ```yaml 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](/fr/actions/reference/workflows-and-actions/events-that-trigger-workflows) ». ### 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 : ```yaml 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 : ```yaml 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](#using-event-activity-types) et [Utilisation de filtres](#using-filters). 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. ```yaml on: label: types: - created push: branches: - main page_build: ``` ## Utilisation des types d'activités événementielles 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..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. ```yaml 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. ```yaml 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](/fr/actions/reference/workflows-and-actions/events-that-trigger-workflows). ## 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. ```yaml on: push: branches: - main - 'releases/**' ``` ### Utilisation de filtres pour cibler des branches spécifiques lors des événements de pull requests. 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`](/fr/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-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 que vous souhaitez une correspondance littérale, vous devez faire précéder chacun de ces caractères spéciaux de `\`. Pour plus d’informations sur les motifs glob, consultez [Syntaxe de flux de travail pour GitHub Actions](/fr/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet). #### 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’un événement `pull_request` se produit pour une pull request ciblant : * 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`) ```yaml on: pull_request: # Sequence of patterns matched against refs/heads branches: - main - 'mona/octocat' - 'releases/**' ``` Si un workflow est ignoré en raison du filtrage de branche, du [filtrage de chemin d’accès](/fr/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore) ou d’un [message de commit](/fr/actions/how-tos/manage-workflow-runs/skip-workflow-runs), les vérifications associées à ce workflow restent alors à l’état « En attente ». Une pull request pour laquelle ces vérifications doivent être réussies ne pourra pas être fusionné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`) ```yaml 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. ```yaml 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`](/fr/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-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 l’[Syntaxe de flux de travail pour GitHub Actions](/fr/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet). #### Exemple : Inclure des branches et des tags 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`) ```yaml 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 de tags 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`) ```yaml 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. ```yaml on: push: branches: - 'releases/**' - '!releases/**-alpha' ``` ### Utilisation de filtres pour cibler des chemins spécifiques pour les événements de push ou de pull request Lorsque vous utilisez les événements `push` et `pull_request`, vous pouvez configurer un flux de travail pour qu’il s’exécute en fonction des chemins d’accès des fichiers modifiés. Les filtres de chemin ne sont pas pris en compte pour les push de tags. 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 motif négatif (préfixé par `!`), placé après un motif positif correspondant, entraîne l’exclusion du chemin d’accès. > * Un motif positif correspondant après une correspondance avec un motif négatif réinclut 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 [Syntaxe de flux de travail pour GitHub Actions](/fr/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet). #### 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`). ```yaml on: push: paths: - '**.js' ``` Si un workflow est ignoré en raison du filtrage de chemin d’accès, du [filtrage de branche](/fr/actions/reference/workflows-and-actions/workflow-syntax#onpull_requestpull_request_targetbranchesbranches-ignore) ou d’un [message de commit](/fr/actions/how-tos/manage-workflow-runs/skip-workflow-runs), les vérifications associées à ce workflow restent alors à l’état « En attente ». Une pull request pour laquelle ces vérifications doivent être réussies ne pourra pas être fusionné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. ```yaml 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`. ```yaml 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 diffs à deux points pour les push et à trois points pour les pull requests : * **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. * **Push vers des branches existantes :** une comparaison à deux points compare directement le SHA de tête et le SHA de base l’un à l’autre. * **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). Dans certaines situations, GitHub Actions applique des limites qui changent la façon dont les flux de travail filtrés s’exécutent : * Si un push contient plus de 1 000 validations, le flux de travail s’exécute **toujours** . * Si la génération du diff dépasse le délai imparti, le flux de travail s’exécutera **toujours**. * Si le différentiel généré contient plus de 3 000 fichiers et que les fichiers que le filtre de flux de travail correspond ne figurent pas dans les 3 000 premiers retournés par le filtre, le flux de travail **ne** s’exécute pas. Si vous observez ces comportements, vous pourriez avoir besoin de rendre vos filtres plus spécifiques, ou de modifier votre façon de travailler avec les push et les pull requests afin de générer des diffs plus simples. Pour plus d’informations, consultez « [Branches](/fr/pull-requests/reference/branches) ». ### 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 motifs glob, consultez [Syntaxe de flux de travail pour GitHub Actions](/fr/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet). 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/` : ```yaml 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` : ```yaml 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`. ```yaml 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](/fr/actions/reference/workflows-and-actions/contexts#inputs-context). > \[!NOTE] > > * Le workflow recevra également les entrées dans le contexte `github.event.inputs`. Les informations dans le contexte `inputs` et le contexte `github.event.inputs` sont identiques, à l’exception du fait que le contexte `inputs` conserve les valeurs booléennes en tant que valeurs booléennes au lieu de les convertir en chaînes. Le type `choice` 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` 25 . > * La charge utile maximale pour `inputs` est de 65 535 caractères. ```yaml 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 définir les sorties qu’un workflow réutilisable met à la disposition d’un workflow appelant. Pour plus d’informations, consultez « [Réutiliser des workflows](/fr/actions/how-tos/reuse-automations/reuse-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](/fr/webhooks/webhook-events-and-payloads) ». 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 : ```yaml jobs: print_context: runs-on: ubuntu-latest steps: - env: EVENT_CONTEXT: ${{ toJSON(github.event) }} run: | echo $EVENT_CONTEXT ``` ### Accéder et utiliser les propriétés d’un événement Vous pouvez utiliser le contexte `github.event` dans votre workflow. Par exemple, le workflow suivant s’exécute lorsqu’une pull request qui change `package*.json`, `.github/CODEOWNERS` ou `.github/workflows/**` est ouverte. Si l’auteur de la pull request (`github.event.pull_request.user.login`) n’est pas `octobot` ou `dependabot[bot]`, le flux de travail utilise GitHub CLI pour étiqueter et commenter la pull request (`github.event.pull_request.number`). ```yaml 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 « [Référence des contextes](/fr/actions/reference/workflows-and-actions/contexts) ». Pour plus d’informations sur les charges utiles d’événement, consultez « [Événements et charges utiles du webhook](/fr/webhooks/webhook-events-and-payloads) ». ## 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`. ```yaml 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 fermeture d’un problème ou d'une pull request. 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 pull request a été fermée, l’étape `if_pr` s'exécutera, mais pas l’étape `if_issue`. ```yaml 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](#using-event-information) ». Pour plus d’informations sur l’utilisation de conditions, consultez « [Évaluer des expressions dans les workflows et les actions.](/fr/actions/reference/workflows-and-actions/expressions) ». ### 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](/fr/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments) ». 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`). ```yaml on: push: branches: - main jobs: build: runs-on: ubuntu-latest steps: - name: build run: | echo 'building' publish: needs: [build] runs-on: ubuntu-latest environment: production steps: - name: publish run: | echo 'publishing' ``` > \[!NOTE] > 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 actuels GitHub . Ils ne sont pas disponibles dans des anciens forfaits, tels que Bronze, Argent ou Or. Pour accéder aux environnements, aux secrets d’environnement et aux branches de déploiement dans des référentiels privés ou internes, vous devez utiliser GitHub Pro, GitHub Teamou GitHub Enterprise. > Si vous êtes sur un plan GitHub Free, GitHub Pro, ou GitHub Team, d’autres règles de protection de déploiement, telles qu’un compte à rebours ou des approbateurs requis, sont uniquement disponibles pour les dépôts publics. ## Événements disponibles Pour obtenir la liste complète des événements disponibles, consultez [Événements qui déclenchent des flux de travail](/fr/actions/reference/workflows-and-actions/events-that-trigger-workflows).