# Syntaxe de flux de travail pour GitHub Actions Un workflow est un processus automatisé configurable qui comprend un ou plusieurs travaux. Vous devez créer un fichier YAML pour définir votre configuration de workflow. > \[!NOTE] > Les exécuteurs hébergés sur GitHub Enterprise Server ne sont pas pris en charge sur GitHub. ## À propos de la syntaxe YAML pour les workflows Les fichiers de workflow utilisent la syntaxe YAML, et doivent avoir une extension de fichier `.yml` ou `.yaml`. Si vous débutez avec YAML et souhaitez en savoir plus, consultez [Découvrir YAML en Y minutes](https://learnxinyminutes.com/docs/yaml/). Vous devez stocker les fichiers de workflow dans le répertoire `.github/workflows` de votre dépôt. ## `name` Nom du workflow. GitHub affiche les noms de vos workflows sous l’onglet « Actions » de votre référentiel. Si vous omettez `name`, GitHub affiche le chemin du fichier de workflow relatif à la racine du référentiel. ## `run-name` Nom des exécutions de workflow généré à partir du workflow. GitHub affiche le nom d’exécution du flux de travail dans la liste des exécutions de flux de travail sous l’onglet « Actions » de votre référentiel. Si `run-name` elle est omise ou n’est qu’un espace blanc, le nom d’exécution est défini sur des informations spécifiques à l’événement pour l’exécution du flux de travail. Par exemple, pour un flux de travail déclenché par un événement `push` ou `pull_request`, il est défini comme le message de commit ou le titre de la pull request. Cette valeur peut inclure des expressions et peut référencer les contextes [`github`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#github-context) et [`inputs`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#inputs-context). ### Exemple de `run-name` ```yaml run-name: Deploy to ${{ inputs.deploy_target }} by @${{ github.actor }} ``` ## `on` Pour déclencher automatiquement un workflow, utilisez `on` pour définir les événements qui peuvent conduire à l’exécution du workflow. Pour obtenir la liste des événements disponibles, consultez [Événements qui déclenchent des flux de travail](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows). Vous pouvez définir un ou plusieurs événements susceptibles de déclencher un workflow, ou définir un calendrier. Vous pouvez également restreindre l’exécution d’un workflow de façon à ce qu’il ne se produise que pour des fichiers, étiquettes ou modifications de branche spécifiques. Les étapes de cette procédure sont décrites dans les sections suivantes. ### 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 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/enterprise-server@3.22/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 types d’activités et de filtres avec plusieurs événements 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: ``` ## `on..types` Utilisez `on..types` pour définir le type d’activité qui déclenchera une exécution de workflow. La plupart des événements GitHub sont déclenchés par plusieurs types d’activité. Par exemple, le déclencheur `label` est déclenché lorsqu’une étiquette est `created`, `edited`ou `deleted`. Le mot clé `types` vous permet d’affiner l’activité qui provoque l’exécution du workflow. Lorsqu’un seul type d’activité déclenche un événement de webhook, le mot clé `types` n’est pas nécessaire. Vous pouvez utiliser un tableau d’événements `types`. Pour plus d’informations sur chaque événement et leurs types d’activité, consultez [Événements qui déclenchent des flux de travail](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows). ```yaml on: label: types: [created, edited] ``` ## `on..` 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/enterprise-server@3.22/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/enterprise-server@3.22/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/**' ``` 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](/fr/enterprise-server@3.22/actions/how-tos/manage-workflow-runs/skip-workflow-runs) » et « [Règles disponibles pour les ensembles de règles](/fr/enterprise-server@3.22/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-workflows-to-pass-before-merging) ». Si un workflow est ignoré en raison du filtrage de branche, du [filtrage de chemin d’accès](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onpushpull_requestpull_request_targetpathspaths-ignore) ou d’un [message de commit](/fr/enterprise-server@3.22/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' ``` ## `on.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/enterprise-server@3.22/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/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet). ### 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`) ```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 tags 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' ``` ## `on..` 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/enterprise-server@3.22/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' ``` 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](/fr/enterprise-server@3.22/actions/how-tos/manage-workflow-runs/skip-workflow-runs) » et « [Règles disponibles pour les ensembles de règles](/fr/enterprise-server@3.22/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-workflows-to-pass-before-merging) ». Si un workflow est ignoré en raison du filtrage de chemin d’accès, du [filtrage de branche](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#onpull_requestpull_request_targetbranchesbranches-ignore) ou d’un [message de commit](/fr/enterprise-server@3.22/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/enterprise-server@3.22/pull-requests/reference/branches) ». ## `on.schedule` Vous pouvez utiliser `on.schedule` pour définir un calendrier pour vos workflows. Utilisez la [syntaxe cron POSIX](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07) pour planifier l’exécution des flux de travail à des moments spécifiques. Par défaut, les flux de travail planifiés s’exécutent au format UTC. Vous pouvez éventuellement spécifier un fuseau horaire à l’aide d’une [chaîne de fuseau horaire IANA](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) pour les flux de travail planifiés prenant en charge. Les flux de travail planifiés s’exécutent sur le dernier commit de la branche par défaut. L’intervalle le plus court auquel vous pouvez exécuter des workflows planifiés est une fois toutes les 5 minutes. > \[!NOTE] > Pour les programmes définis `timezone` sur un fuseau horaire qui observe l'heure d'été, pendant le passage à l'heure d'été, les workflows planifiés pendant les heures sautées avancent jusqu'à la prochaine heure valide. Par exemple, un horaire de 2 h 30 avance à 3 h 00. La syntaxe cron comporte cinq champs séparés par un espace, chaque champ représentant une unité de temps. ```text ┌───────────── minute (0 - 59) │ ┌───────────── hour (0 - 23) │ │ ┌───────────── day of the month (1 - 31) │ │ │ ┌───────────── month (1 - 12 or JAN-DEC) │ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT) │ │ │ │ │ * * * * * ``` Vous pouvez utiliser ces opérateurs dans n'importe lequel de ces cinq champs : | Opérateur | Description | Exemple | | ----------------------------------------------------------------------------------------------------- | ------------------------------ | ------- | | \* | Valeur quelconque | | | `15 * * * *` s'exécute à chaque minute 15 de chaque heure de chaque jour. | | | | , | Séparateur de liste de valeurs | | | `2,10 4,5 * * *` s'exécute à la 2ème et à la 10ème minute de chaque 4ème et 5ème heure de la journée. | | | | - | Plage de valeurs | | | `30 4-6 * * *` s'exécute à la 30e minute des 4e, 5e et 6e heures. | | | | / | Valeurs d'étape | | | `20/15 * * * *` s'exécute toutes les 15 minutes de la minute 20 à 59 (minutes 20, 35 et 50). | | | Cet exemple déclenche l’exécution du flux de travail à 5h30 dans le fuseau horaire de New York, du lundi au vendredi : ```yaml on: schedule: - cron: '30 5 * * 1-5' timezone: "America/New_York" ``` Un seul workflow peut être déclenché par plusieurs événements `schedule`. Accédez à l’événement `schedule` qui a déclenché le flux de travail via le contexte `github.event.schedule`. Dans cet exemple, le flux de travail est déclenché à 5h30 UTC tous les jours du lundi au jeudi, et à 17h30 UTC les mardis et jeudis, mais l’étape `Not on Monday or Wednesday` est ignorée les lundis et mercredis. ```yaml on: schedule: - cron: '30 5 * * 1,3' - cron: '30 5,17 * * 2,4' jobs: test_schedule: runs-on: ubuntu-latest steps: - name: Not on Monday or Wednesday if: github.event.schedule != '30 5 * * 1,3' run: echo "This step will be skipped on Monday and Wednesday" - name: Every time run: echo "This step will always run" ``` Pour plus d’informations sur les événements `schedule`, consultez [Événements qui déclenchent des flux de travail](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule). ## `on.workflow_call` Utilisez `on.workflow_call` pour définir les entrées et sorties d’un workflow réutilisable. Vous pouvez également mapper les secrets disponibles au workflow appelé. Pour plus d’informations sur les flux de travail réutilisables, consultez « [Réutiliser des workflows](/fr/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows) ». ## `on.workflow_call.inputs` Lorsque vous utilisez le mot clé `workflow_call`, vous pouvez éventuellement spécifier des entrées qui sont passées au workflow appelé à partir du workflow appelant. Pour plus d’informations sur le mot clé `workflow_call`, consultez « [Événements qui déclenchent des flux de travail](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_call) ». En plus des paramètres d’entrée standard disponibles, `on.workflow_call.inputs` nécessite un paramètre `type`. Pour plus d’informations, consultez [`on.workflow_call.inputs..type`](#onworkflow_callinputsinput_idtype). Si aucun paramètre `default` n’est défini, la valeur par défaut de l’entrée est `false` pour une valeur booléenne, `0` pour un nombre et `""` pour une chaîne. Dans le workflow appelé, vous pouvez utiliser le contexte `inputs` pour référencer une entrée. Pour plus d’informations, consultez « [Référence des contextes](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#inputs-context) ». Si un workflow appelant passe une entrée qui n’est pas spécifiée dans le workflow appelé, cela entraîne une erreur. ### Exemple de `on.workflow_call.inputs` ```yaml on: workflow_call: inputs: username: description: 'A username passed from the caller workflow' default: 'john-doe' required: false type: string jobs: print-username: runs-on: ubuntu-latest steps: - name: Print the input name to STDOUT run: echo The username is ${{ inputs.username }} ``` Pour plus d’informations, consultez « [Réutiliser des workflows](/fr/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows) ». ## `on.workflow_call.inputs..type` Obligatoire si l’entrée est définie pour le mot clé `on.workflow_call`. La valeur de ce paramètre est une chaîne spécifiant le type de données de l’entrée. Il doit s’agir de l’une des valeurs suivantes : `boolean`, `number` ou `string`. ## `on.workflow_call.outputs` Carte des sorties pour un workflow appelé. Les sorties de workflow appelé sont disponibles pour tous les travaux en aval dans le workflow appelant. Chaque sortie a un identificateur, une `description,` facultative et un `value.`. Le `value` doit être défini sur la valeur d'une sortie d'un travail dans le workflow appelé. Dans l’exemple ci-dessous, deux sorties sont définies pour ce workflow réutilisable : `workflow_output1` et `workflow_output2`. Celles-ci sont mappées aux sorties appelées `job_output1` et `job_output2`, toutes les deux provenant d’un travail appelé `my_job`. ### Exemple de `on.workflow_call.outputs` ```yaml on: workflow_call: # Map the workflow outputs to job outputs outputs: workflow_output1: description: "The first job output" value: ${{ jobs.my_job.outputs.job_output1 }} workflow_output2: description: "The second job output" value: ${{ jobs.my_job.outputs.job_output2 }} ``` Pour plus d’informations sur la façon de référencer une sortie de travail, consultez [`jobs..outputs`](#jobsjob_idoutputs). Pour plus d’informations, consultez « [Réutiliser des workflows](/fr/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows) ». ## `on.workflow_call.secrets` Une carte des secrets qui peuvent être utilisés dans le workflow appelé. Dans le workflow appelé, vous pouvez utiliser le contexte `secrets` pour faire référence à un secret. > \[!NOTE] > Si vous transmettez le secret à un flux de travail réutilisable imbriqué, vous devez utiliser à nouveau [`jobs..secrets`](#jobsjob_idsecrets)pour transmettre le secret. Pour plus d’informations, consultez « [Réutiliser des workflows](/fr/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows#passing-secrets-to-nested-workflows) ». Si un workflow appelant passe un secret qui n’est pas spécifié dans le workflow appelé, cela entraîne une erreur. ### Exemple de `on.workflow_call.secrets` ```yaml on: workflow_call: secrets: access-token: description: 'A token passed from the caller workflow' required: false jobs: pass-secret-to-action: runs-on: ubuntu-latest steps: # passing the secret to an action - name: Pass the received secret to an action uses: ./.github/actions/my-action with: token: ${{ secrets.access-token }} # passing the secret to a nested reusable workflow pass-secret-to-workflow: uses: ./.github/workflows/my-workflow secrets: token: ${{ secrets.access-token }} ``` ## `on.workflow_call.secrets.` Identificateur de chaîne à associer au secret. ## `on.workflow_call.secrets..required` Valeur booléenne spécifiant si le secret doit être fourni. ## `on.workflow_run.` 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/enterprise-server@3.22/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' ``` ## `on.workflow_dispatch` 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. ## `on.workflow_dispatch.inputs` Le workflow déclenché reçoit les entrées dans le contexte `inputs`. Pour plus d’informations, consultez [Contextes](/fr/enterprise-server@3.22/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` 10 . > * La charge utile maximale pour `inputs` est de 65 535 caractères. ### Exemple de `on.workflow_dispatch.inputs` ```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 }} ``` ## `on.workflow_dispatch.inputs..required` Valeur booléenne spécifiant si l’entrée doit être fournie. ## `on.workflow_dispatch.inputs..type` La valeur de ce paramètre est une chaîne spécifiant le type de données de l’entrée. Il doit s’agir de l’une des valeurs suivantes : `boolean`, `choice`, `number`, `environment` ou `string`. ## `permissions` Vous pouvez utiliser `permissions` pour modifier les autorisations par défaut octroyées à `GITHUB_TOKEN`, en ajoutant ou en supprimant l’accès selon les besoins, afin d’autoriser uniquement l’accès minimal nécessaire. Pour plus d’informations, consultez « [Utiliser GITHUB\_TOKEN pour l’authentification dans les flux de travail](/fr/enterprise-server@3.22/actions/tutorials/authenticate-with-github_token#modifying-the-permissions-for-the-github_token) ». Vous pouvez utiliser `permissions` en tant que clé de niveau supérieur, à appliquer à tous les travaux du workflow ou à des travaux spécifiques. Quand vous ajoutez la clé `permissions` à un travail spécifique, toutes les actions et commandes d’exécution de ce travail qui utilisent `GITHUB_TOKEN` obtiennent les droits d’accès que vous spécifiez. Pour plus d’informations, consultez [`jobs..permissions`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idpermissions). Les propriétaires d’une organisation ou d’une entreprise peuvent restreindre l’accès en écriture au `GITHUB_TOKEN` niveau du référentiel. Pour plus d’informations, consultez [Désactivation ou limitation des GitHub Actions pour votre organisation](/fr/enterprise-server@3.22/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#setting-the-permissions-of-the-github_token-for-your-organization) et [Application de stratégies pour GitHub Actions dans votre entreprise](/fr/enterprise-server@3.22/admin/enforcing-policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-github-actions-in-your-enterprise#enforcing-a-policy-for-workflow-permissions-in-your-enterprise). Lorsqu'un workflow est déclenché par l'événement [`pull_request_target`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull_request_target), le `GITHUB_TOKEN` reçoit une autorisation de dépôt en lecture/écriture, même s'il est déclenché à partir d'un fork public. Pour plus d’informations, consultez « [Événements qui déclenchent des flux de travail](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#pull_request_target) ». À chacune des autorisations disponibles (cf. tableau ci-dessous), vous pouvez attribuer l'un des niveaux d'accès suivants : `read` (le cas échéant), `write` ou `none`. `write` comprend `read`. Si vous spécifiez l'accès pour chacune de ces autorisations, toutes celles qui ne sont pas spécifiées seront définies comme `none`. Autorisations disponibles et détails de l'action déclenchée par chacune : | Autorisation | Autorise une action à l’aide de `GITHUB_TOKEN` à | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `actions` | Utilisez GitHub Actions. Par exemple, `actions: write` permet à une action d’annuler l’exécution d’un workflow. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-actions) ». | | | | | | | | `checks` | Utilisez des exécutions de vérifications et des suites de vérifications. Par exemple, `checks: write` permet à une action de créer l’exécution d’une vérification. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-checks) ». | | | | | `contents` | Utilisez le contenu du référentiel. Par exemple, `contents: read` autorise une action à répertorier les validations et `contents: write` autorise l’action à créer une mise en production. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-contents) ». | | `deployments` | Utilisez des déploiements. Par exemple, `deployments: write` permet à une action de créer un nouveau déploiement. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-deployments) ». | | `discussions` | Tâche avec des discussions GitHub. Par exemple, `discussions: write` permet à une action de fermer ou de supprimer une discussion. Pour plus d’informations, consultez « [Utilisation de l’API GraphQL pour les discussions](/fr/enterprise-server@3.22/graphql/guides/using-the-graphql-api-for-discussions) ». | | | | | `issues` | Tâche avec des problèmes. Par exemple, `issues: write` permet à une action d’ajouter un commentaire à un problème. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-issues) ». | | `packages` | Tâche avec des packages GitHub. Par exemple, `packages: write` permet à une action de charger et de publier des packages sur des packages GitHub. Pour plus d’informations, consultez « [À propos des autorisations pour les packages GitHub](/fr/enterprise-server@3.22/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries) ». | | `pages` | Tâche avec des pages GitHub. Par exemple, `pages: write` autorise une action à demander une build GitHub Pages. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pages) ». | | `pull-requests` | Tâche avec des requêtes de tirage. Par exemple, `pull-requests: write` permet à une action d’ajouter une étiquette à une demande de tirage. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pull-requests) ». | | `security-events` | Tâche avec des alertes de numérisation de code GitHub. Par exemple, `security-events: read` autorise l'action de répertorier les alertes de numérisation de code pour le référentiel, et `security-events: write` autorise l'action de mettre à jour le statut d'une alerte de numérisation de code. Pour plus d’informations, consultez [Autorisations du référentiel pour « Alertes d’analyse du code ».](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-code-scanning-alerts)

| | Les alertes de Dependabot et de scans de secrets ne peuvent pas être lues avec cette autorisation et nécessitent une application GitHub ou un personal access token. Pour plus d’informations, consultez [Autorisations de référentiel pour les « alertes Dependabot »](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-dependabot-alerts) et [les autorisations de référentiel pour les « alertes d’analyse de secrets »](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-secret-scanning-alerts) dans « Autorisations requises pour GitHub Apps ». | | | `statuses` | Tâche avec des statuts attribués. Par exemple, `statuses:read` autorise une action à répertorier les états de validation pour une référence donnée. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-commit-statuses) ». | | | | ### Définition de l’accès pour les périmètres `GITHUB_TOKEN` Vous pouvez définir l’accès que le `GITHUB_TOKEN` autorise en spécifiant `read`, `write` ou `none` comme valeur des autorisations disponibles dans la clé `permissions`. ```yaml permissions: actions: read|write|none checks: read|write|none contents: read|write|none deployments: read|write|none issues: read|write|none discussions: read|write|none packages: read|write|none pages: read|write|none pull-requests: read|write|none security-events: read|write|none statuses: read|write|none ``` Si vous spécifiez l’accès pour l’une de ces autorisations, toutes celles qui ne sont pas spécifiées sont définies sur `none`. Vous pouvez utiliser la syntaxe suivante pour définir l'un des accès `read-all` ou `write-all` à toutes les autorisations disponibles : ```yaml permissions: read-all ``` ```yaml permissions: write-all ``` Vous pouvez utiliser la syntaxe suivante afin de désactiver les autorisations pour toutes les autorisations disponibles : ```yaml permissions: {} ``` #### Modification des autorisations dans un référentiel dupliqué Vous pouvez utiliser la clé `permissions` afin d’ajouter et de supprimer des autorisations d’accès en lecture pour les dépôts dupliqués. Toutefois, en règle générale, vous ne pouvez pas octroyer d’accès en écriture. L’exception à ce comportement est lorsqu’un utilisateur administrateur a sélectionné l'option **Envoyer des jetons d'écriture vers les workflows à partir des demandes de tirage** dans les paramètres GitHub Actions. Pour plus d’informations, consultez « [Gestion des paramètres de GitHub Actions pour un référentiel](/fr/enterprise-server@3.22/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories) ». ### Calcul des autorisations pour une tâche de workflow Les autorisations pour le `GITHUB_TOKEN` sont initialement définies sur le paramètre par défaut pour l’entreprise, l’organisation ou le dépôt. Si la valeur par défaut est définie sur les autorisations restreintes à l’un de ces niveaux, cela s’applique aux dépôts appropriés. Par exemple, si vous choisissez la valeur par défaut restreinte au niveau de l’organisation, tous les dépôts de cette organisation utiliseront les autorisations restreintes comme valeur par défaut. Les autorisations sont ensuite ajustées en fonction de n’importe quelle configuration dans le fichier de workflow, d’abord au niveau du workflow, puis au niveau du travail. Enfin, si le flux de travail a été déclenché par un événement de demande de tirage autre que depuis un `pull_request_target` référentiel forké, et que le paramètre **Envoyer des jetons d’écriture aux flux de travail des demandes de tirage** n’est pas sélectionné, les autorisations sont ajustées pour convertir toutes les autorisations d’écriture en lecture seule. ### Définition des autorisations `GITHUB_TOKEN` pour tous les travaux d’un workflow Vous pouvez spécifier `permissions` au niveau supérieur d’un workflow, afin que le paramètre s’applique à tous les travaux du workflow. #### Exemple : définition des autorisations `GITHUB_TOKEN` pour un workflow entier Cet exemple montre les autorisations définies pour `GITHUB_TOKEN`, qui s’appliquent à tous les travaux du workflow. Toutes les autorisations se voient octroyer un accès en lecture. ```yaml name: "My workflow" on: [ push ] permissions: read-all jobs: ... ``` ### Utilisation de la clé `permissions` pour les référentiels dupliqués Vous pouvez utiliser la clé `permissions` afin d’ajouter et de supprimer des autorisations d’accès `read` pour les dépôts dupliqués. Toutefois, en règle générale, vous ne pouvez pas octroyer d’accès `write`. L’exception à ce comportement se produit lorsqu’un utilisateur administrateur a sélectionné l’option **Envoyer les jetons d’écriture aux workflows à partir des pull requests** dans les GitHub Actionsparamètres. Pour plus d’informations, consultez « [Gestion des paramètres de GitHub Actions pour un référentiel](/fr/enterprise-server@3.22/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories) ». ### Autorisations pour les exécutions de flux de travail déclenchées par Dependabot Les exécutions de workflow déclenchées par des Dependabot pull requests s’exécutent comme si elles provenaient d’un dépôt dupliqué, et utilisent donc un `GITHUB_TOKEN` en lecture seule. Ces exécutions de workflow ne peuvent pas accéder à des secrets. Pour plus d’informations sur les stratégies de sécurisation de ces workflows, consultez [Informations de référence sur l’utilisation sécurisée](/fr/enterprise-server@3.22/actions/reference/security/secure-use). ## `env` Un ensemble (`map`) de variables qui sont disponibles pour les étapes de tous les travaux du workflow. Vous pouvez également définir des variables qui sont disponibles uniquement pour les étapes d’un seul travail ou pour une seule étape. Pour plus d’informations, consultez [`jobs..env`](#jobsjob_idenv) et [`jobs..steps[*].env`](#jobsjob_idstepsenv). Les variables du mappage `env` ne peuvent pas être définies d’après d’autres variables du mappage. Quand plusieurs variables d’environnement sont définies avec le même nom, GitHub utilise la variable la plus spécifique. Par exemple, une variable d’environnement définie dans une étape remplace les variables d’environnement du travail et du workflow portant le même nom, pendant l’exécution de l’étape. Une variable d’environnement définie pour un travail remplace une variable de workflow de même nom, pendant l’exécution du travail. ### Exemple de `env` ```yaml env: SERVER: production ``` ## `defaults` Utilisez `defaults` pour créer un `map` de paramètres par défaut qui s’appliqueront à tous les travaux du workflow. Vous pouvez également définir des paramètres par défaut uniquement disponibles pour un travail. Pour plus d’informations, consultez [`jobs..defaults`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iddefaults). Quand plusieurs paramètres par défaut sont définis avec le même nom, GitHub utilise le paramètre par défaut le plus spécifique. Par exemple, un paramètre par défaut défini dans un travail remplace un paramètre par défaut portant le même nom défini dans un workflow. ## `defaults.run` Vous pouvez utiliser `defaults.run` afin de fournir les options `shell` et `working-directory` par défaut pour toutes les étapes [`run`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsrun) d’un workflow. Vous pouvez également définir pour `run` des paramètres par défaut qui sont disponibles uniquement pour un travail. Pour plus d’informations, consultez [`jobs..defaults.run`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iddefaultsrun). Vous ne pouvez pas utiliser de contextes ou d’expressions dans ce mot clé. Quand plusieurs paramètres par défaut sont définis avec le même nom, GitHub utilise le paramètre par défaut le plus spécifique. Par exemple, un paramètre par défaut défini dans un travail remplace un paramètre par défaut portant le même nom défini dans un workflow. ### Exemple : Définir l’interpréteur de commandes et le répertoire de travail par défaut ```yaml defaults: run: shell: bash working-directory: ./scripts ``` ## `defaults.run.shell` Utilise `shell` pour définir le `shell` d'une étape. Ce mot clé peut référencer plusieurs contextes. Pour plus d’informations, consultez [Contextes](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#context-availability). | Plateforme prise en charge | Paramètre `shell` | Description | Commande exécutée en interne | | -------------------------- | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- | | Linux / macOS | unspecified | Interpréteur de commandes par défaut sur les plateformes non Windows. Notez que cette opération exécute une commande différente par rapport à quand `bash` est spécifié explicitement. Si `bash` n’est pas trouvé dans le chemin, il est considéré comme `sh`. | `bash -e {0}` | | Tous | `bash` | Interpréteur de commandes par défaut sur les plateformes non Windows avec `sh` comme valeur de secours. Lors de la spécification d’un interpréteur de commandes Bash sur Windows, l’interpréteur de commandes Bash inclus avec Git pour Windows est utilisé. | `bash --noprofile --norc -eo pipefail {0}` | | Tous | `pwsh` | PowerShell Core. GitHub ajoute l’extension `.ps1` au nom de votre script. | `pwsh -command ". '{0}'"` | | Tous | `python` | Exécute la commande Python. | `python {0}` | | Linux / macOS | `sh` | Comportement de secours pour les plateformes non Windows si aucun interpréteur de commandes n’est fourni et que `bash` ne se trouve pas dans le chemin. | `sh -e {0}` | | Windows | `cmd` | GitHub ajoute l’extension `.cmd` au nom de votre script et se substitue à `{0}`. | `%ComSpec% /D /E:ON /V:OFF /S /C "CALL "{0}""`. | | Windows | `pwsh` | Il s’agit de l’interpréteur de commandes par défaut utilisé sur Windows. PowerShell Core. GitHub ajoute l’extension `.ps1` au nom de votre script. Si *PowerShell Core* n’est pas installé sur votre exécuteur Windows auto-hébergé, *PowerShell Desktop* est utilisé à la place. | `pwsh -command ". '{0}'"`. | | Windows | `powershell` | PowerShell Desktop. GitHub ajoute l’extension `.ps1` au nom de votre script. | `powershell -command ". '{0}'"`. | Quand plusieurs paramètres par défaut sont définis avec le même nom, GitHub utilise le paramètre par défaut le plus spécifique. Par exemple, un paramètre par défaut défini dans un travail remplace un paramètre par défaut portant le même nom défini dans un workflow. ## `defaults.run.working-directory` Utilise `working-directory` pour définir le répertoire de travail pour le `shell` d'une étape. Ce mot clé peut référencer plusieurs contextes. Pour plus d’informations, consultez [Contextes](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#context-availability). > \[!TIP] > Assurez-vous que le `working-directory` que vous affectez existe sur l'exécuteur avant toute exécution du shell dans ce dernier. > Quand plusieurs paramètres par défaut sont définis avec le même nom, GitHub utilise le paramètre par défaut le plus spécifique. Par exemple, un paramètre par défaut défini dans un travail remplace un paramètre par défaut portant le même nom défini dans un workflow. ## `concurrency` Utilisez `concurrency` pour vérifier qu’un seul travail ou workflow utilisant le même groupe d’accès concurrentiel s’exécute à la fois. Un groupe d’accès concurrentiel peut être n’importe quelle chaîne ou expression. L’expression peut uniquement utiliser les contextes [`github`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#github-context), [`inputs`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#inputs-context) et [`vars`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#vars-context). Pour plus d’informations sur les expressions, consultez [Évaluer des expressions dans les workflows et les actions.](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions). Vous pouvez également spécifier `concurrency` au niveau du travail. Pour plus d’informations, consultez [`jobs..concurrency`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idconcurrency). Cela signifie qu’il peut y avoir au plus un travail en cours d’exécution et un travail en attente dans un groupe de concurrence à tout moment. Quand un travail ou un workflow simultané est mis en file d’attente, si un autre travail ou workflow utilisant le même groupe d’accès concurrentiel dans le dépôt est en cours d’exécution, le travail ou le workflow en file d’attente a la valeur `pending`. Tout travail `pending` ou flux de travail existant dans le même groupe de concurrence, s'il existe, sera annulé et le nouveau travail ou flux de travail en file d'attente prendra sa place. Pour annuler également un travail ou un workflow en cours d’exécution dans le même groupe d’accès concurrentiel, spécifiez `cancel-in-progress: true`. Pour annuler de façon conditionnelle les travaux ou les flux de travail en cours d’exécution dans le même groupe d’accès concurrentiel, vous pouvez spécifier `cancel-in-progress` en tant qu’expression avec l’un des contextes d’expression autorisés. > \[!NOTE] > > * Le nom du groupe de concurrence n'est pas sensible à la casse. Par exemple, `prod` et `Prod` seront traités comme le même groupe de concurrence. > * Les tâches ou exécutions de flux de travail dans le même groupe de concurrence sont traitées selon l'ordre PEPS (premier entré, premier sorti) en fonction du moment où chacune a commencé à attendre dans le groupe de concurrence, plutôt que du moment où chaque flux de travail a été distribué. Étant donné que l’heure de début réelle d’un travail ou d’une exécution peut varier, l’ordre n’est pas garanti. ### Exemple : utilisation de la concurrence et du comportement par défaut Le comportement par défaut consiste à autoriser l’exécution simultanée de GitHub Actions plusieurs travaux ou flux de travail. Le mot clé `concurrency` vous permet de contrôler la concurrence des exécutions de flux de travail. Par exemple, vous pouvez utiliser le mot clé `concurrency` immédiatement après le lieu de définition des conditions de déclenchement afin de limiter la concurrence des exécutions de l'ensemble du flux de travail pour une branche spécifique : ```yaml on: push: branches: - main concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true ``` Vous pouvez également limiter la concurrence des projets au sein d'un flux de travail en utilisant le mot-clé `concurrency` au niveau du projet : ```yaml on: push: branches: - main jobs: job-1: runs-on: ubuntu-latest concurrency: group: example-group cancel-in-progress: true ``` ### Exemple : groupes de concurrence Les groupes de concurrence permettent de gérer et de limiter l'exécution des flux de travail ou des projets qui partagent la même clé de concurrence. La clé `concurrency` est utilisée pour regrouper des flux de travail ou des projets ensemble dans un groupe de concurrence. Lorsque vous définissez une `concurrency` clé, GitHub Actions garantit qu’un seul flux de travail ou travail avec cette clé s’exécute à tout moment. Si une nouvelle exécution ou un travail commence avec la même `concurrency` clé, GitHub Actions annulera toute exécution ou travail déjà en cours avec cette clé. La clé `concurrency` peut être une chaîne codée en dur, ou il peut s'agir d'une expression dynamique qui inclut des variables de contexte. Il est possible de définir des conditions de concurrence dans votre flux de travail afin que le flux de travail ou le projet fasse partie d'un groupe de concurrence. En d'autres termes, lorsqu'un flux de travail ou un projet est lancé, GitHub annule tous les flux de travail ou projets déjà en cours dans le même groupe de concurrence. Cette fonction est utile dans les scénarios où vous souhaitez empêcher les exécutions parallèles pour un certain ensemble de flux de travail ou de projets, comme ceux utilisés pour les déploiements dans un environnement intermédiaire, afin d'éviter les actions susceptibles de provoquer des conflits ou de consommer plus de ressources qu'il n'est nécessaire. Dans cet exemple, `job-1` fait partie d'un groupe de concurrence nommé `staging_environment`. En d'autres termes, si une nouvelle exécution de `job-1` est déclenchée, toutes les exécutions du même projet dans le groupe de concurrence `staging_environment` qui sont déjà en cours seront annulées. ```yaml jobs: job-1: runs-on: ubuntu-latest concurrency: group: staging_environment cancel-in-progress: true ``` Par ailleurs, l'utilisation d'une expression dynamique comme `concurrency: ci-${{ github.ref }}` dans votre flux de travail signifie que le flux de travail ou le projet fera partie d'un groupe de concurrence dont le nom `ci-` est suivi de la référence de la branche ou de la balise qui a déclenché le flux de travail. Dans cet exemple, si un nouveau commit est poussé vers la branche principale alors qu'une exécution précédente est toujours en cours, cette dernière sera annulée et la nouvelle commencera. ```yaml on: push: branches: - main concurrency: group: ci-${{ github.ref }} cancel-in-progress: true ``` ### Exemple : Utilisation de la concurrence pour annuler un travail ou une exécution en cours Pour utiliser la concurrence pour annuler un travail ou une exécution en cours dans GitHub Actions, vous pouvez utiliser la clé `concurrency` avec l’option `cancel-in-progress` définie sur `true`. ```yaml concurrency: group: ${{ github.ref }} cancel-in-progress: true ``` Remarquez que dans cet exemple, sans définir de groupe de concurrence particulier, GitHub Actions annulera *toute* exécution en cours de la tâche ou du flux de travail. ### Exemple : Utilisation d’une valeur de secours Si vous créez le nom de groupe avec une propriété définie uniquement pour des événements spécifiques, vous pouvez utiliser une valeur de secours. Par exemple, `github.head_ref` est défini uniquement pour les événements `pull_request`. Si votre workflow répond à d’autres événements en plus des événements `pull_request`, vous devez fournir une valeur de secours pour éviter une erreur de syntaxe. Le groupe d’accès concurrentiel suivant annule les travaux ou les exécutions en cours pour les événements `pull_request` uniquement. Si `github.head_ref` n’est pas défini, le groupe d’accès concurrent utilise l’ID d’exécution, qui offre la garantie d’être à la fois unique et défini pour l’exécution. ```yaml concurrency: group: ${{ github.head_ref || github.run_id }} cancel-in-progress: true ``` ### Exemple : Annuler uniquement les travaux ou les exécutions en cours pour le workflow actuel Si vous avez plusieurs workflows dans le même dépôt, les noms de groupes de concurrence doivent être uniques entre les workflows pour éviter d'annuler des tâches ou des exécutions en cours provenant d'autres workflows. Sinon, tout travail en cours ou en attente est annulé, quel que soit le workflow. Pour annuler uniquement les exécutions en cours du même workflow, vous pouvez utiliser la propriété `github.workflow` afin de créer le groupe d’accès concurrentiel : ```yaml concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true ``` ### Exemple : Annuler uniquement les travaux en cours sur des branches spécifiques Si vous souhaitez annuler des travaux en cours sur certaines branches, mais pas sur d’autres, vous pouvez utiliser des expressions conditionnelles avec `cancel-in-progress`. Par exemple, vous pouvez procéder ainsi si vous souhaitez annuler les processus en cours sur les branches de développement, mais pas sur les branches de release. Pour n’annuler que les exécutions en cours du même workflow lorsqu’il n’est pas exécuté sur une branche de publication, vous pouvez définir `cancel-in-progress` comme une expression similaire à la suivante : ```yaml concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: ${{ !contains(github.ref, 'release/')}} ``` Dans cet exemple, plusieurs envois push vers une branche `release/1.2.3` n’annulent pas les exécutions en cours. Les envois (push) vers une autre branche, par exemple `main`, annulent les exécutions en cours. ## `jobs` Une exécution de workflow est composée d’un ou de plusieurs `jobs`, qui s’exécutent en parallèle par défaut. Pour exécuter des travaux de manière séquentielle, vous pouvez définir des dépendances par rapport à d’autres travaux à l’aide du mot clé `jobs..needs`. Chaque tâche s’exécute dans un environnement de runner spécifié par `runs-on`. Vous pouvez exécuter un nombre illimité de travaux tant que vous respectez les limites d’utilisation du workflow. Pour plus d’informations, consultez [Facturation et utilisation](/fr/enterprise-server@3.22/actions/concepts/billing-and-usage) for GitHub- pour les coureurs hébergés par et [Limites d’Actions](/fr/enterprise-server@3.22/actions/reference/limits) pour les limites d’utilisation des coureurs auto-hébergés. Si vous devez trouver l’identificateur unique d’un travail en cours d’exécution dans un flux de travail, vous pouvez utiliser l’API GitHub . Pour plus d’informations, consultez « [Points de terminaison d’API REST pour GitHub Actions](/fr/enterprise-server@3.22/rest/actions#workflow-jobs) ». ## `jobs.` Utilisez `jobs.` pour attribuer un identificateur unique à votre travail. La clé `job_id` est une chaîne et sa valeur est une carte des données de configuration du travail. Vous devez remplacer `` par une chaîne propre à l’objet `jobs`. `` doit commencer par une lettre ou par `_`, et contenir uniquement des caractères alphanumériques, des `-` ou des `_`. ### Exemple : Création de travaux Dans cet exemple, deux travaux ont été créés, et leurs valeurs `job_id` sont `my_first_job` et `my_second_job`. ```yaml jobs: my_first_job: name: My first job my_second_job: name: My second job ``` ## `jobs..name` Utilisez `jobs..name` pour définir un nom pour le travail, qui s’affiche sur l’interface utilisateur GitHub. ## `jobs..permissions` Pour un travail spécifique, vous pouvez utiliser `jobs..permissions` afin de modifier les autorisations par défaut octroyées à `GITHUB_TOKEN`, en ajoutant ou en supprimant l’accès selon les besoins, afin d’autoriser uniquement l’accès minimal nécessaire. Pour plus d’informations, consultez « [Utiliser GITHUB\_TOKEN pour l’authentification dans les flux de travail](/fr/enterprise-server@3.22/actions/tutorials/authenticate-with-github_token#modifying-the-permissions-for-the-github_token) ». En spécifiant l’autorisation dans une définition de travail, vous pouvez configurer un ensemble d’autorisations différent pour le `GITHUB_TOKEN` de chaque travail, le cas échéant. Vous pouvez également spécifier les autorisations relatives à tous les travaux du workflow. Pour plus d’informations sur la définition d’autorisations au niveau du workflow, consultez [`permissions`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#permissions). À chacune des autorisations disponibles (cf. tableau ci-dessous), vous pouvez attribuer l'un des niveaux d'accès suivants : `read` (le cas échéant), `write` ou `none`. `write` comprend `read`. Si vous spécifiez l'accès pour chacune de ces autorisations, toutes celles qui ne sont pas spécifiées seront définies comme `none`. Autorisations disponibles et détails de l'action déclenchée par chacune : | Autorisation | Autorise une action à l’aide de `GITHUB_TOKEN` à | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `actions` | Utilisez GitHub Actions. Par exemple, `actions: write` permet à une action d’annuler l’exécution d’un workflow. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-actions) ». | | | | | | | | `checks` | Utilisez des exécutions de vérifications et des suites de vérifications. Par exemple, `checks: write` permet à une action de créer l’exécution d’une vérification. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-checks) ». | | | | | `contents` | Utilisez le contenu du référentiel. Par exemple, `contents: read` autorise une action à répertorier les validations et `contents: write` autorise l’action à créer une mise en production. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-contents) ». | | `deployments` | Utilisez des déploiements. Par exemple, `deployments: write` permet à une action de créer un nouveau déploiement. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-deployments) ». | | `discussions` | Tâche avec des discussions GitHub. Par exemple, `discussions: write` permet à une action de fermer ou de supprimer une discussion. Pour plus d’informations, consultez « [Utilisation de l’API GraphQL pour les discussions](/fr/enterprise-server@3.22/graphql/guides/using-the-graphql-api-for-discussions) ». | | | | | `issues` | Tâche avec des problèmes. Par exemple, `issues: write` permet à une action d’ajouter un commentaire à un problème. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-issues) ». | | `packages` | Tâche avec des packages GitHub. Par exemple, `packages: write` permet à une action de charger et de publier des packages sur des packages GitHub. Pour plus d’informations, consultez « [À propos des autorisations pour les packages GitHub](/fr/enterprise-server@3.22/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries) ». | | `pages` | Tâche avec des pages GitHub. Par exemple, `pages: write` autorise une action à demander une build GitHub Pages. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pages) ». | | `pull-requests` | Tâche avec des requêtes de tirage. Par exemple, `pull-requests: write` permet à une action d’ajouter une étiquette à une demande de tirage. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pull-requests) ». | | `security-events` | Tâche avec des alertes de numérisation de code GitHub. Par exemple, `security-events: read` autorise l'action de répertorier les alertes de numérisation de code pour le référentiel, et `security-events: write` autorise l'action de mettre à jour le statut d'une alerte de numérisation de code. Pour plus d’informations, consultez [Autorisations du référentiel pour « Alertes d’analyse du code ».](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-code-scanning-alerts)

| | Les alertes de Dependabot et de scans de secrets ne peuvent pas être lues avec cette autorisation et nécessitent une application GitHub ou un personal access token. Pour plus d’informations, consultez [Autorisations de référentiel pour les « alertes Dependabot »](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-dependabot-alerts) et [les autorisations de référentiel pour les « alertes d’analyse de secrets »](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-secret-scanning-alerts) dans « Autorisations requises pour GitHub Apps ». | | | `statuses` | Tâche avec des statuts attribués. Par exemple, `statuses:read` autorise une action à répertorier les états de validation pour une référence donnée. Pour plus d’informations, consultez « [Autorisations requises pour les applications GitHub](/fr/enterprise-server@3.22/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-commit-statuses) ». | | | | ### Définition de l’accès pour les périmètres `GITHUB_TOKEN` Vous pouvez définir l’accès que le `GITHUB_TOKEN` autorise en spécifiant `read`, `write` ou `none` comme valeur des autorisations disponibles dans la clé `permissions`. ```yaml permissions: actions: read|write|none checks: read|write|none contents: read|write|none deployments: read|write|none issues: read|write|none discussions: read|write|none packages: read|write|none pages: read|write|none pull-requests: read|write|none security-events: read|write|none statuses: read|write|none ``` Si vous spécifiez l’accès pour l’une de ces autorisations, toutes celles qui ne sont pas spécifiées sont définies sur `none`. Vous pouvez utiliser la syntaxe suivante pour définir l'un des accès `read-all` ou `write-all` à toutes les autorisations disponibles : ```yaml permissions: read-all ``` ```yaml permissions: write-all ``` Vous pouvez utiliser la syntaxe suivante afin de désactiver les autorisations pour toutes les autorisations disponibles : ```yaml permissions: {} ``` #### Modification des autorisations dans un référentiel dupliqué Vous pouvez utiliser la clé `permissions` afin d’ajouter et de supprimer des autorisations d’accès en lecture pour les dépôts dupliqués. Toutefois, en règle générale, vous ne pouvez pas octroyer d’accès en écriture. L’exception à ce comportement est lorsqu’un utilisateur administrateur a sélectionné l'option **Envoyer des jetons d'écriture vers les workflows à partir des demandes de tirage** dans les paramètres GitHub Actions. Pour plus d’informations, consultez « [Gestion des paramètres de GitHub Actions pour un référentiel](/fr/enterprise-server@3.22/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-forks-of-private-repositories) ». #### Exemple : définition des autorisations `GITHUB_TOKEN` pour un travail dans un workflow Cet exemple montre les autorisations définies pour `GITHUB_TOKEN`, qui s’appliquent uniquement au travail nommé `stale`. L’accès en écriture est octroyé pour les autorisations `issues` et `pull-requests`. Toutes les autres autorisations n’ont aucun accès. ```yaml jobs: stale: runs-on: ubuntu-latest permissions: issues: write pull-requests: write steps: - uses: actions/stale@v10 ``` ## `jobs..needs` Utilisez `jobs..needs` pour identifier les travaux à accomplir avant l’exécution de ce travail. Il peut s’agir d’une chaîne ou d’un tableau de chaînes. Si une tâche échoue ou est ignorée, toutes les tâches qui en dépendent sont ignorées, à moins que ces tâches n’utilisent une expression conditionnelle qui permet à la tâche de se poursuivre. Si une exécution contient une série de tâches qui dépendent les unes des autres, un échec ou le fait qu’une tâche soit ignorée affecte toutes les tâches de la chaîne de dépendance à partir du point d’échec ou d’omission. Si vous souhaitez qu’un travail s’exécute même si un travail dont il dépend n’a pas réussi, utilisez l’expression conditionnelle `always()` dans `jobs..if`. ### Exemple : Exigence de réussite de travaux dépendants ```yaml jobs: job1: job2: needs: job1 job3: needs: [job1, job2] ``` Dans cet exemple, `job1` doit être correctement accompli avant que `job2` commence, et `job3` attend que `job1` et `job2` soient accomplis. Les travaux dans cet exemple s’exécutent séquentiellement : 1. `job1` 2. `job2` 3. `job3` ### Exemple : Non-exigence de réussite de travaux dépendants ```yaml jobs: job1: job2: needs: job1 job3: if: ${{ always() }} needs: [job1, job2] ``` Dans cet exemple, `job3` utilise l’expression conditionnelle `always()` afin de toujours s’exécuter après que `job1` et `job2` ont été effectués avec ou sans succès. Pour plus d’informations, consultez « [Évaluer des expressions dans les workflows et les actions.](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions#status-check-functions) ». ## `jobs..if` Vous pouvez utiliser le `jobs..if` conditionnel pour empêcher l’exécution d’un travail, sauf si une condition est remplie. Vous pouvez utiliser n’importe quel contexte et n’importe quelle expression pris en charge pour créer un conditionnel. Pour plus d’informations sur les contextes pris en charge dans cette clé, consultez [Référence des contextes](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#context-availability). > \[!NOTE] > La condition `jobs..if` est évaluée avant que [`jobs..strategy.matrix`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstrategymatrix) soit appliqué. Quand vous utilisez des expressions dans un conditionnel `if`, vous pouvez omettre la syntaxe de l’expression `${{ }}` parce que GitHub Actions évalue automatiquement le conditionnel `if` en tant qu’expression. Toutefois, cette exception ne s’applique pas partout. Vous devez utiliser la syntaxe d’expression `${{ }}` ou l’échappement avec `''`, `""` ou `()` lorsque l’expression commence par `!`, car `!` est une notation réservée au format YAML. Par exemple : ```yaml if: ${{ ! startsWith(github.ref, 'refs/tags/') }} ``` Pour plus d’informations, consultez [Évaluer des expressions dans les workflows et les actions.](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions). ### Exemple : Exécuter un travail uniquement pour un dépôt spécifique Cet exemple utilise `if` pour contrôler le moment où le travail `production-deploy` peut s’exécuter. Il s’exécute uniquement si le dépôt se nomme `octo-repo-prod`, et s’il se trouve dans l’organisation `octo-org`. Sinon, le travail est marqué comme étant *ignoré*. ```yaml copy name: example-workflow on: [push] jobs: production-deploy: if: github.repository == 'octo-org/octo-repo-prod' runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - uses: actions/setup-node@v7 with: node-version: '14' - run: npm install -g bats ``` ## `jobs..runs-on` Utilisez `jobs..runs-on` pour définir le type de machine sur laquelle le travail doit être exécuté. * La machine de destination peut être un [runner auto-hébergé](#choosing-self-hosted-runners). * Vous pouvez cibler les coureurs en fonction des étiquettes qui leur ont été attribuées, de leur appartenance à un groupe ou d'une combinaison de ces éléments. * Vous pouvez fournir `runs-on` sous la forme suivante : * Une seule chaîne de caractères * Une seule variable contenant une chaîne * Un tableau de chaînes, des variables contenant des chaînes ou une combinaison des deux * Une paire `key: value` utilisant les clés `group` ou `labels` * Si vous spécifiez un tableau de chaînes ou de variables, votre workflow s’exécute sur n’importe quel exécuteur correspondant à toutes les valeurs `runs-on` spécifiées. Par exemple, ici, la tâche ne s’exécutera que sur un exécuteur auto-hébergé portant les étiquettes `linux`, `x64` et `gpu` : ```yaml runs-on: [self-hosted, linux, x64, gpu] ``` Pour plus d’informations, consultez [Choisir des runners auto-hébergés](#choosing-self-hosted-runners). * Vous pouvez mélanger des chaînes et des variables dans un tableau. Par exemple : ```yaml on: workflow_dispatch: inputs: chosen-os: required: true type: choice options: - Ubuntu - macOS jobs: test: runs-on: [self-hosted, "${{ inputs.chosen-os }}"] steps: - run: echo Hello world! ``` * Si vous souhaitez exécuter votre workflow sur plusieurs machines, utilisez [`jobs..strategy`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstrategy). > \[!NOTE] > Les guillemets ne sont pas obligatoires autour de chaînes simples comme `self-hosted`, mais elles sont requises pour les expressions comme`"${{ inputs.chosen-os }}"` . ### ChoisirGitHub- des coureurs hébergés par > \[!NOTE] > Les exécuteurs hébergés sur GitHub Enterprise Server ne sont pas pris en charge sur GitHub. ### Choix des exécuteurs auto-hébergés Si vous souhaitez spécifier un exécuteur autohébergé pour votre travail, configurez `runs-on` dans votre fichier de workflow avec des étiquettes d’exécuteur autohébergé. Les runners auto-hébergés peuvent avoir le `self-hosted` label. Lors de la configuration d’un exécuteur auto-hébergé, nous inclurons l’étiquette `self-hosted` par défaut. Vous pouvez utiliser l’option `--no-default-labels` pour empêcher l’application du label auto-hébergé. Les étiquettes peuvent être utilisées pour créer des options de ciblage pour les exécuteurs, telles que le système d’exploitation ou l’architecture. Nous recommandons de fournir un tableau d’étiquettes qui commence par `self-hosted` (ceci doit être listé en premier) et inclut ensuite des étiquettes supplémentaires si nécessaire. Quand vous spécifiez un tableau d’étiquettes, les travaux sont mis en file d’attente sur des exécuteurs qui comportent toutes les étiquettes que vous indiquez. > \[!NOTE] Actions Runner Controller ne prend pas en charge le `self-hosted` label. #### Exemple : Utilisation d’étiquettes pour la sélection des exécuteurs ```yaml runs-on: [self-hosted, linux] ``` Pour plus d’informations, consultez « [Exécuteurs auto-hébergés](/fr/enterprise-server@3.22/actions/concepts/runners/self-hosted-runners) » et « [Utilisation d’exécuteurs auto-hébergés dans un workflow](/fr/enterprise-server@3.22/actions/how-tos/manage-runners/self-hosted-runners/use-in-a-workflow) ». ### Choix des exécuteurs dans un groupe Vous pouvez utiliser `runs-on` pour cibler des groupes de runners, de sorte que la tâche s’exécute sur n’importe quel runner membre de ce groupe. Pour un contrôle plus précis, vous pouvez également combiner des groupes d’exécuteurs avec des étiquettes. #### Exemple : utilisation de groupes pour contrôler où les travaux sont exécutés Dans cet exemple, des runners ont été ajoutés à un groupe appelé `build-runners`. La clé `runs-on` envoie le travail à n’importe quel exécuteur disponible dans le groupe `build-runners` : ```yaml name: learn-github-actions on: [push] jobs: check-bats-version: runs-on: group: build-runners steps: - uses: actions/checkout@v6 - uses: actions/setup-node@v7 with: node-version: '14' - run: npm install -g bats - run: bats -v ``` #### Exemple : combinaison de groupes et d’étiquettes Quand vous combinez des groupes et des étiquettes, l’exécuteur doit satisfaire aux deux exigences pour pouvoir exécuter le travail. Dans cet exemple, la clé `runs-on` combine `group` et `labels` de sorte que le job soit acheminé vers n’importe quel runner disponible dans le groupe qui possède également une étiquette correspondante : ```yaml name: learn-github-actions on: [push] jobs: check-bats-version: runs-on: group: ubuntu-runners labels: ubuntu-24.04-16core steps: - uses: actions/checkout@v6 - uses: actions/setup-node@v7 with: node-version: '14' - run: npm install -g bats - run: bats -v ``` #### Exemple : utiliser des préfixes pour différencier les groupes de runners Par exemple, si vous avez un groupe d’exécuteurs nommé `my-group` dans l’organisation et un autre nommé `my-group` dans l’entreprise, vous pouvez mettre à jour votre fichier de workflow pour utiliser `org/my-group` ou `ent/my-group` afin de les différencier. Utilisation de `org/`: ```yaml runs-on: group: org/my-group labels: [ self-hosted, label-1 ] ``` Utilisation de `ent/`: ```yaml runs-on: group: ent/my-group labels: [ self-hosted, label-1 ] ``` ## `jobs..environment` Utilisez `jobs..environment` pour définir l’environnement référencé par le travail. Vous pouvez fournir l’environnement en tant qu’environnement `name` uniquement, ou en tant qu’objet d’environnement avec `name` et `url`. L’URL est mappée à `environment_url` dans l’API des déploiements. Pour plus d’informations sur l’API des déploiements, consultez [Points de terminaison d’API REST pour les référentiels](/fr/enterprise-server@3.22/rest/repos#deployments). > \[!NOTE] > Toutes les règles liées à la protection du déploiement doivent être respectées avant qu’un projet faisant référence à l’environnement ne soit envoyé à un exécuteur. Pour plus d’informations, consultez « [Gestion des environnements pour le déploiement](/fr/enterprise-server@3.22/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments) ». ### Exemple : Utilisation d’un seul nom d’environnement ```yaml environment: staging_environment ``` ### Exemple : Utilisation du nom et de l’URL de l’environnement ```yaml environment: name: production_environment url: https://github.com ``` La valeur de `url` peut être une expression. Contextes d’expression autorisés : [`github`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#github-context), [`inputs`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#inputs-context), [`vars`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#vars-context), [`needs`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#needs-context), [`strategy`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#strategy-context), [`matrix`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#matrix-context), [`job`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#job-context), [`runner`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#runner-context), [`env`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#env-context) et [`steps`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#steps-context). Pour plus d’informations sur les expressions, consultez [Évaluer des expressions dans les workflows et les actions.](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions). ### Exemple : Utilisation de la sortie en tant qu’URL ```yaml environment: name: production_environment url: ${{ steps.step_id.outputs.url_output }} ``` La valeur de `name` peut être une expression. Contextes d’expression autorisés : [`github`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#github-context), [`inputs`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#inputs-context), [`vars`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#vars-context), [`needs`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#needs-context), [`strategy`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#strategy-context) et [`matrix`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#matrix-context). Pour plus d’informations sur les expressions, consultez [Évaluer des expressions dans les workflows et les actions.](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions). ### Exemple : Utilisation d’une expression comme nom d’environnement ```yaml environment: name: ${{ github.ref_name }} ``` ## `jobs..concurrency` Vous pouvez utiliser `jobs..concurrency` pour vous assurer qu’un seul travail ou workflow utilisant le même groupe d’accès concurrentiel s’exécute à la fois. Un groupe de concurrence peut être n’importe quelle chaîne ou expression. Contextes d’expression autorisés : [`github`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#github-context), [`inputs`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#inputs-context), [`vars`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#vars-context), [`needs`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#needs-context), [`strategy`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#strategy-context) et [`matrix`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#matrix-context). Pour plus d’informations sur les expressions, consultez [Évaluer des expressions dans les workflows et les actions.](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions). Vous pouvez également spécifier `concurrency` au niveau du workflow. Pour plus d’informations, consultez [`concurrency`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#concurrency). Cela signifie qu’il peut y avoir au plus un travail en cours d’exécution et un travail en attente dans un groupe de concurrence à tout moment. Quand un travail ou un workflow simultané est mis en file d’attente, si un autre travail ou workflow utilisant le même groupe d’accès concurrentiel dans le dépôt est en cours d’exécution, le travail ou le workflow en file d’attente a la valeur `pending`. Tout travail `pending` ou flux de travail existant dans le même groupe de concurrence, s'il existe, sera annulé et le nouveau travail ou flux de travail en file d'attente prendra sa place. Pour annuler également un travail ou un workflow en cours d’exécution dans le même groupe d’accès concurrentiel, spécifiez `cancel-in-progress: true`. Pour annuler de façon conditionnelle les travaux ou les flux de travail en cours d’exécution dans le même groupe d’accès concurrentiel, vous pouvez spécifier `cancel-in-progress` en tant qu’expression avec l’un des contextes d’expression autorisés. > \[!NOTE] > > * Le nom du groupe de concurrence n'est pas sensible à la casse. Par exemple, `prod` et `Prod` seront traités comme le même groupe de concurrence. > * Les tâches ou exécutions de flux de travail dans le même groupe de concurrence sont traitées selon l'ordre PEPS (premier entré, premier sorti) en fonction du moment où chacune a commencé à attendre dans le groupe de concurrence, plutôt que du moment où chaque flux de travail a été distribué. Étant donné que l’heure de début réelle d’un travail ou d’une exécution peut varier, l’ordre n’est pas garanti. ### Exemple : utilisation de la concurrence et du comportement par défaut Le comportement par défaut consiste à autoriser l’exécution simultanée de GitHub Actions plusieurs travaux ou flux de travail. Le mot clé `concurrency` vous permet de contrôler la concurrence des exécutions de flux de travail. Par exemple, vous pouvez utiliser le mot clé `concurrency` immédiatement après le lieu de définition des conditions de déclenchement afin de limiter la concurrence des exécutions de l'ensemble du flux de travail pour une branche spécifique : ```yaml on: push: branches: - main concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true ``` Vous pouvez également limiter la concurrence des projets au sein d'un flux de travail en utilisant le mot-clé `concurrency` au niveau du projet : ```yaml on: push: branches: - main jobs: job-1: runs-on: ubuntu-latest concurrency: group: example-group cancel-in-progress: true ``` ### Exemple : groupes de concurrence Les groupes de concurrence permettent de gérer et de limiter l'exécution des flux de travail ou des projets qui partagent la même clé de concurrence. La clé `concurrency` est utilisée pour regrouper des flux de travail ou des projets ensemble dans un groupe de concurrence. Lorsque vous définissez une `concurrency` clé, GitHub Actions garantit qu’un seul flux de travail ou travail avec cette clé s’exécute à tout moment. Si une nouvelle exécution ou un travail commence avec la même `concurrency` clé, GitHub Actions annulera toute exécution ou travail déjà en cours avec cette clé. La clé `concurrency` peut être une chaîne codée en dur, ou il peut s'agir d'une expression dynamique qui inclut des variables de contexte. Il est possible de définir des conditions de concurrence dans votre flux de travail afin que le flux de travail ou le projet fasse partie d'un groupe de concurrence. En d'autres termes, lorsqu'un flux de travail ou un projet est lancé, GitHub annule tous les flux de travail ou projets déjà en cours dans le même groupe de concurrence. Cette fonction est utile dans les scénarios où vous souhaitez empêcher les exécutions parallèles pour un certain ensemble de flux de travail ou de projets, comme ceux utilisés pour les déploiements dans un environnement intermédiaire, afin d'éviter les actions susceptibles de provoquer des conflits ou de consommer plus de ressources qu'il n'est nécessaire. Dans cet exemple, `job-1` fait partie d'un groupe de concurrence nommé `staging_environment`. En d'autres termes, si une nouvelle exécution de `job-1` est déclenchée, toutes les exécutions du même projet dans le groupe de concurrence `staging_environment` qui sont déjà en cours seront annulées. ```yaml jobs: job-1: runs-on: ubuntu-latest concurrency: group: staging_environment cancel-in-progress: true ``` Par ailleurs, l'utilisation d'une expression dynamique comme `concurrency: ci-${{ github.ref }}` dans votre flux de travail signifie que le flux de travail ou le projet fera partie d'un groupe de concurrence dont le nom `ci-` est suivi de la référence de la branche ou de la balise qui a déclenché le flux de travail. Dans cet exemple, si un nouveau commit est poussé vers la branche principale alors qu'une exécution précédente est toujours en cours, cette dernière sera annulée et la nouvelle commencera. ```yaml on: push: branches: - main concurrency: group: ci-${{ github.ref }} cancel-in-progress: true ``` ### Exemple : Utilisation de la concurrence pour annuler un travail ou une exécution en cours Pour utiliser la concurrence pour annuler un travail ou une exécution en cours dans GitHub Actions, vous pouvez utiliser la clé `concurrency` avec l’option `cancel-in-progress` définie sur `true`. ```yaml concurrency: group: ${{ github.ref }} cancel-in-progress: true ``` Remarquez que dans cet exemple, sans définir de groupe de concurrence particulier, GitHub Actions annulera *toute* exécution en cours de la tâche ou du flux de travail. ### Exemple : Utilisation d’une valeur de secours Si vous créez le nom de groupe avec une propriété définie uniquement pour des événements spécifiques, vous pouvez utiliser une valeur de secours. Par exemple, `github.head_ref` est défini uniquement pour les événements `pull_request`. Si votre workflow répond à d’autres événements en plus des événements `pull_request`, vous devez fournir une valeur de secours pour éviter une erreur de syntaxe. Le groupe d’accès concurrentiel suivant annule les travaux ou les exécutions en cours pour les événements `pull_request` uniquement. Si `github.head_ref` n’est pas défini, le groupe d’accès concurrent utilise l’ID d’exécution, qui offre la garantie d’être à la fois unique et défini pour l’exécution. ```yaml concurrency: group: ${{ github.head_ref || github.run_id }} cancel-in-progress: true ``` ### Exemple : Annuler uniquement les travaux ou les exécutions en cours pour le workflow actuel Si vous avez plusieurs workflows dans le même dépôt, les noms de groupes de concurrence doivent être uniques entre les workflows pour éviter d'annuler des tâches ou des exécutions en cours provenant d'autres workflows. Sinon, tout travail en cours ou en attente est annulé, quel que soit le workflow. Pour annuler uniquement les exécutions en cours du même workflow, vous pouvez utiliser la propriété `github.workflow` afin de créer le groupe d’accès concurrentiel : ```yaml concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: true ``` ### Exemple : Annuler uniquement les travaux en cours sur des branches spécifiques Si vous souhaitez annuler des travaux en cours sur certaines branches, mais pas sur d’autres, vous pouvez utiliser des expressions conditionnelles avec `cancel-in-progress`. Par exemple, vous pouvez procéder ainsi si vous souhaitez annuler les processus en cours sur les branches de développement, mais pas sur les branches de release. Pour n’annuler que les exécutions en cours du même workflow lorsqu’il n’est pas exécuté sur une branche de publication, vous pouvez définir `cancel-in-progress` comme une expression similaire à la suivante : ```yaml concurrency: group: ${{ github.workflow }}-${{ github.ref }} cancel-in-progress: ${{ !contains(github.ref, 'release/')}} ``` Dans cet exemple, plusieurs envois push vers une branche `release/1.2.3` n’annulent pas les exécutions en cours. Les envois (push) vers une autre branche, par exemple `main`, annulent les exécutions en cours. ## `jobs..outputs` Vous pouvez utiliser `jobs..outputs` pour créer une `map` de sorties pour un travail. Les résultats de tâche sont disponibles pour toutes les tâches en aval qui dépendent de cette tâche. Pour plus d’informations sur la définition des dépendances de travail, consultez [`jobs..needs`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idneeds). La taille maximale des sorties est de 1 Mo par projet. La taille totale maximale de toutes les sorties d’une exécution de workflow est de 50 Mo. La taille est approximative et basée sur l’encodage UTF-16. Les sorties de travail contenant des expressions sont évaluées sur l’exécuteur à la fin de chaque travail. Les sorties contenant des secrets sont expurgées sur l'exécuteur et ne sont pas envoyées à GitHub Actions. Si une production est ignorée, car elle peut contenir un secret, le message d’avertissement suivant s’affiche : « Ignorer la production `{output.Key}`, car elle peut contenir un secret ». Pour plus d’informations sur la gestion des secrets, consultez [Exemple : masquage et transfert d’un secret entre des projets ou des flux de travail](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#example-masking-and-passing-a-secret-between-jobs-or-workflows). Pour utiliser les sorties de travail dans un travail dépendant, vous pouvez utiliser le contexte `needs`. Pour plus d’informations, consultez « [Référence des contextes](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#needs-context) ». ### Exemple : Définition de sorties pour un travail ```yaml jobs: job1: runs-on: ubuntu-latest # Map a step output to a job output outputs: output1: ${{ steps.step1.outputs.test }} output2: ${{ steps.step2.outputs.test }} steps: - id: step1 run: echo "test=hello" >> "$GITHUB_OUTPUT" - id: step2 run: echo "test=world" >> "$GITHUB_OUTPUT" job2: runs-on: ubuntu-latest needs: job1 steps: - env: OUTPUT1: ${{needs.job1.outputs.output1}} OUTPUT2: ${{needs.job1.outputs.output2}} run: echo "$OUTPUT1 $OUTPUT2" ``` ### Utilisation des résultats d'une tâche dans une tâche matricielle Les matrices peuvent être utilisées pour générer plusieurs sorties de noms différents. Lors de l'utilisation d'une matrice, les résultats des travaux seront combinés à partir de tous les travaux à l'intérieur de la matrice. ```yaml jobs: job1: runs-on: ubuntu-latest outputs: output_1: ${{ steps.gen_output.outputs.output_1 }} output_2: ${{ steps.gen_output.outputs.output_2 }} output_3: ${{ steps.gen_output.outputs.output_3 }} strategy: matrix: version: [1, 2, 3] steps: - name: Generate output id: gen_output run: | version="${{ matrix.version }}" echo "output_${version}=${version}" >> "$GITHUB_OUTPUT" job2: runs-on: ubuntu-latest needs: [job1] steps: # Will show # { # "output_1": "1", # "output_2": "2", # "output_3": "3" # } - run: echo '${{ toJSON(needs.job1.outputs) }}' ``` > \[!WARNING] > Actions ne garantit pas l'ordre d'exécution des tâches matricielles. Veillez à ce que le nom de la sortie soit unique, sinon le dernier travail matriciel exécuté remplacera la valeur de la sortie. ## `jobs..env` Ensemble (`map`) de variables qui sont disponibles pour toutes les étapes de la tâche. Vous pouvez définir des variables pour l’ensemble du workflow ou pour une étape individuelle. Pour plus d’informations, consultez [`env`](#env) et [`jobs..steps[*].env`](#jobsjob_idstepsenv). Quand plusieurs variables d’environnement sont définies avec le même nom, GitHub utilise la variable la plus spécifique. Par exemple, une variable d’environnement définie dans une étape remplace les variables d’environnement du travail et du workflow portant le même nom, pendant l’exécution de l’étape. Une variable d’environnement définie pour un travail remplace une variable de workflow de même nom, pendant l’exécution du travail. ### Exemple de `jobs..env` ```yaml jobs: job1: env: FIRST_NAME: Mona ``` ## `jobs..defaults` Utilisez `jobs..defaults` pour créer un `map` des paramètres par défaut applicable à toutes les étapes du travail. Vous pouvez également définir des paramètres par défaut pour l’ensemble du workflow. Pour plus d’informations, consultez [`defaults`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#defaults). Quand plusieurs paramètres par défaut sont définis avec le même nom, GitHub utilise le paramètre par défaut le plus spécifique. Par exemple, un paramètre par défaut défini dans un travail remplace un paramètre par défaut portant le même nom défini dans un workflow. ## `jobs..defaults.run` Utilisez `jobs..defaults.run` pour fournir le `shell` par défaut, et `working-directory` pour toutes les étapes `run` du travail. Vous pouvez fournir des options `shell` et `working-directory` par défaut pour toutes les étapes [`run`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsrun) d’un job. Vous pouvez également définir des paramètres par défaut de `run` pour l’ensemble du workflow. Pour plus d’informations, consultez [`defaults.run`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#defaultsrun). Ces éléments peuvent être remplacés aux niveaux `jobs..defaults.run` et `jobs..steps[*].run`. Quand plusieurs paramètres par défaut sont définis avec le même nom, GitHub utilise le paramètre par défaut le plus spécifique. Par exemple, un paramètre par défaut défini dans un travail remplace un paramètre par défaut portant le même nom défini dans un workflow. ## `jobs..defaults.run.shell` Utilise `shell` pour définir le `shell` d'une étape. Ce mot clé peut référencer plusieurs contextes. Pour plus d’informations, consultez [Contextes](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#context-availability). | Plateforme prise en charge | Paramètre `shell` | Description | Commande exécutée en interne | | -------------------------- | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- | | Linux / macOS | unspecified | Interpréteur de commandes par défaut sur les plateformes non Windows. Notez que cette opération exécute une commande différente par rapport à quand `bash` est spécifié explicitement. Si `bash` n’est pas trouvé dans le chemin, il est considéré comme `sh`. | `bash -e {0}` | | Tous | `bash` | Interpréteur de commandes par défaut sur les plateformes non Windows avec `sh` comme valeur de secours. Lors de la spécification d’un interpréteur de commandes Bash sur Windows, l’interpréteur de commandes Bash inclus avec Git pour Windows est utilisé. | `bash --noprofile --norc -eo pipefail {0}` | | Tous | `pwsh` | PowerShell Core. GitHub ajoute l’extension `.ps1` au nom de votre script. | `pwsh -command ". '{0}'"` | | Tous | `python` | Exécute la commande Python. | `python {0}` | | Linux / macOS | `sh` | Comportement de secours pour les plateformes non Windows si aucun interpréteur de commandes n’est fourni et que `bash` ne se trouve pas dans le chemin. | `sh -e {0}` | | Windows | `cmd` | GitHub ajoute l’extension `.cmd` au nom de votre script et se substitue à `{0}`. | `%ComSpec% /D /E:ON /V:OFF /S /C "CALL "{0}""`. | | Windows | `pwsh` | Il s’agit de l’interpréteur de commandes par défaut utilisé sur Windows. PowerShell Core. GitHub ajoute l’extension `.ps1` au nom de votre script. Si *PowerShell Core* n’est pas installé sur votre exécuteur Windows auto-hébergé, *PowerShell Desktop* est utilisé à la place. | `pwsh -command ". '{0}'"`. | | Windows | `powershell` | PowerShell Desktop. GitHub ajoute l’extension `.ps1` au nom de votre script. | `powershell -command ". '{0}'"`. | Quand plusieurs paramètres par défaut sont définis avec le même nom, GitHub utilise le paramètre par défaut le plus spécifique. Par exemple, un paramètre par défaut défini dans un travail remplace un paramètre par défaut portant le même nom défini dans un workflow. ## `jobs..defaults.run.working-directory` Utilise `working-directory` pour définir le répertoire de travail pour le `shell` d'une étape. Ce mot clé peut référencer plusieurs contextes. Pour plus d’informations, consultez [Contextes](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#context-availability). > \[!TIP] > Assurez-vous que le `working-directory` que vous affectez existe sur l'exécuteur avant toute exécution du shell dans ce dernier. > Quand plusieurs paramètres par défaut sont définis avec le même nom, GitHub utilise le paramètre par défaut le plus spécifique. Par exemple, un paramètre par défaut défini dans un travail remplace un paramètre par défaut portant le même nom défini dans un workflow. ### Exemple : Définition d’options d’étape `run` par défaut pour un travail ```yaml jobs: job1: runs-on: ubuntu-latest defaults: run: shell: bash working-directory: ./scripts ``` ## `jobs..steps` Un travail contient une séquence de tâches appelées `steps`. Les étapes peuvent exécuter des commandes, exécuter des tâches de configuration ou exécuter une action dans votre dépôt ou dans un dépôt public, ou une action publiée dans un registre Docker. Toutes les étapes n’exécutent pas d’actions, mais toutes les actions s’exécutent en tant qu’étape. Chaque étape s’exécute dans son propre processus dans l’environnement de l’exécuteur et a accès à l’espace de travail et au système de fichiers. Étant donné que les étapes s’exécutent dans leur propre processus, les modifications apportées aux variables d’environnement ne sont pas conservées d’une étapes à l’autre. GitHub fournit des étapes intégrées pour configurer et exécuter une tâche. GitHub affiche uniquement les 1 000 premières vérifications. Toutefois, vous pouvez exécuter un nombre illimité d’étapes tant que vous êtes dans les limites d’utilisation du flux de travail. Pour plus d’informations, consultez [Facturation et utilisation](/fr/enterprise-server@3.22/actions/concepts/billing-and-usage) for GitHub- pour les coureurs hébergés par et [Limites d’Actions](/fr/enterprise-server@3.22/actions/reference/limits) pour les limites d’utilisation des coureurs auto-hébergés. ### Exemple de `jobs..steps` ```yaml name: Greeting from Mona on: push jobs: my-job: name: My Job runs-on: ubuntu-latest steps: - name: Print a greeting env: MY_VAR: Hi there! My name is FIRST_NAME: Mona MIDDLE_NAME: The LAST_NAME: Octocat run: | echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME. ``` ## `jobs..steps[*].id` Identificateur unique pour l’étape. Vous pouvez utiliser l’`id` pour référencer l’étape dans des contextes. Pour plus d’informations, consultez « [Référence des contextes](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts) ». ## `jobs..steps[*].if` Vous pouvez utiliser la condition `if` pour empêcher l’exécution d’une étape si une condition n’est pas remplie. Vous pouvez utiliser n’importe quel contexte et n’importe quelle expression pris en charge pour créer un conditionnel. Pour plus d’informations sur les contextes pris en charge dans cette clé, consultez [Référence des contextes](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#context-availability). Quand vous utilisez des expressions dans un conditionnel `if`, vous pouvez omettre la syntaxe de l’expression `${{ }}` parce que GitHub Actions évalue automatiquement le conditionnel `if` en tant qu’expression. Toutefois, cette exception ne s’applique pas partout. Vous devez utiliser la syntaxe d’expression `${{ }}` ou l’échappement avec `''`, `""` ou `()` lorsque l’expression commence par `!`, car `!` est une notation réservée au format YAML. Par exemple : ```yaml if: ${{ ! startsWith(github.ref, 'refs/tags/') }} ``` Pour plus d’informations, consultez [Évaluer des expressions dans les workflows et les actions.](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions). ### Exemple : Utilisation des contextes Cette étape s’exécute uniquement lorsque le type d’événement est `pull_request` et que l’action d’événement est `unassigned`. ```yaml steps: - name: My first step if: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }} run: echo This event is a pull request that had an assignee removed. ``` ### Exemple : Utilisation des fonctions de vérification d’état L’étape `my backup step` s’exécute uniquement lorsque l’étape précédente d’un travail échoue. Pour plus d’informations, consultez « [Évaluer des expressions dans les workflows et les actions.](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions#status-check-functions) ». ```yaml steps: - name: My first step uses: octo-org/action-name@main - name: My backup step if: ${{ failure() }} uses: actions/heroku@1.0.0 ``` ### Exemple : Utilisation de secrets Les secrets ne peuvent pas être directement référencés dans les conditions `if:`. Au lieu de cela, envisagez de définir des secrets en tant que variables d’environnement au niveau du travail, puis de référencer les variables d’environnement pour exécuter des étapes de manière conditionnelle dans le travail. Si aucun secret n’a été défini, la valeur de retour d’une expression référençant le secret (par `${{ secrets.SuperSecret }}` exemple) est une chaîne vide. ```yaml name: Run a step if a secret has been set on: push jobs: my-jobname: runs-on: ubuntu-latest env: super_secret: ${{ secrets.SuperSecret }} steps: - if: ${{ env.super_secret != '' }} run: echo 'This step will only run if the secret has a value set.' - if: ${{ env.super_secret == '' }} run: echo 'This step will only run if the secret does not have a value set.' ``` Pour plus d’informations, consultez « [Référence des contextes](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#context-availability) » et « [Utilisation de secrets dans GitHub Actions](/fr/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets) ». ## `jobs..steps[*].name` Nom de votre étape à afficher sur GitHub. ## `jobs..steps[*].uses` Sélectionne une action à exécuter dans le cadre d’une étape de votre travail. Une action est une unité de code réutilisable. Vous pouvez utiliser une action définie dans le même dépôt que le workflow, dans un dépôt public ou dans une [image conteneur Docker publiée](https://hub.docker.com/). Nous vous recommandons vivement d’inclure la version de l’action que vous utilisez en spécifiant une étiquette Git ref, SHA ou Docker. Si vous ne spécifiez pas de version, cela peut arrêter vos workflows ou provoquer un comportement inattendu lorsque le propriétaire de l’action publie une mise à jour. * L’utilisation du SHA de commit d’une version d’action publiée est la solution la plus sûre en termes de stabilité et de sécurité. * Si l’action publie des balises de version majeure, vous devez vous attendre à recevoir des correctifs critiques et des correctifs de sécurité, tout en conservant la compatibilité. Notez que ce comportement est à la discrétion de l’auteur de l’action. * L’utilisation de la branche par défaut d’une action peut être pratique. Toutefois, si un utilisateur publie une nouvelle version majeure avec un changement entraînant une rupture, votre flux de travail pourrait être interrompu. Certaines actions nécessitent des entrées que vous devez définir à l’aide du mot clé [`with`](#jobsjob_idstepswith). Examinez le fichier README de l’action pour déterminer les entrées nécessaires. Les actions sont des fichiers JavaScript ou des conteneurs Docker. Si l’action que vous utilisez est un conteneur Docker, vous devez exécuter le travail dans un environnement Linux. Pour plus d’informations, consultez la page [`runs-on`](#jobsjob_idruns-on). ### Exemple : Utilisation d’actions versionnées ```yaml steps: # Reference a specific commit - uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3 # Reference the major version of a release - uses: actions/checkout@v6 # Reference a specific version - uses: actions/checkout@v6.2.0 # Reference a branch - uses: actions/checkout@main ``` ### Exemple : Utilisation d’une action publique `{owner}/{repo}@{ref}` Vous pouvez spécifier une branche, une référence ou une sha dans un référentiel public GitHub . ```yaml jobs: my_first_job: steps: - name: My first step # Uses the default branch of a public repository uses: actions/heroku@main - name: My second step # Uses a specific version tag of a public repository uses: actions/aws@v2.0.1 ``` ### Exemple : Utilisation d’une action publique dans un sous-répertoire `{owner}/{repo}/{path}@{ref}` Un sous-répertoire dans un dépôt publicGitHubsur une branche, un ref ou un SHA spécifique. ```yaml jobs: my_first_job: steps: - name: My first step uses: actions/aws/ec2@main ``` ### Exemple : Utilisation d’une action dans le même référentiel que le flux de travail au niveau de la validation en cours d’exécution (recommandé) `$/path/to/action` Le `$/` préfixe est la référence de référentiel automatique. Il fait référence à une action stockée dans le même référentiel que le flux de travail ou l’action en cours d’exécution et se résout vers ce référentiel au niveau de la validation en cours d’exécution (la même SHA que le flux de travail ou l’action en cours d’exécution). Vous n’avez pas besoin d’extraire d’abord le référentiel. Il est donc recommandé de référencer une action dans son propre référentiel. La `$/` syntaxe n’est pas disponible dans GitHub Enterprise Server. Une `$/` référence ne doit pas inclure de `@{ref}` suffixe. La référence est toujours la validation du flux de travail ou de l’action en cours d’exécution. Par conséquent, une référence telle qu’elle `$/actions/my-action@v1` n’est pas valide. `$/` résout toujours par rapport au référentiel du fichier dans lequel il apparaît, et non dans le référentiel qui l’a appelé. Par exemple, si un flux de travail réutilisable dans un référentiel est appelé par un flux de travail dans un autre référentiel, une `$/` référence dans le flux de travail appelé se résout vers le référentiel du flux de travail appelé, et non le référentiel du flux de travail appelant. Cela rend `$/` fiable la composition d’action, où un chemin relatif `./` est résolu par rapport à ce qui est extrait dans l’espace de travail de l’appelant. Pour une utilisation `$/` dans les étapes d’une action composite, consultez [Référence syntaxique des métadonnées](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/metadata-syntax#runsstepsuses). Le tableau suivant compare les façons de référencer une action. | Syntax | Aboutit à | Recommandé pour | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | | `$/path/to/action` | Le même dépôt que le workflow ou l’action en cours d’exécution, au niveau de la validation en cours d’exécution | Actions dans le même référentiel | | `{owner}/{repo}@{ref}` | Référentiel spécifié à la référence spécifiée | Actions dans un autre référentiel | | `./path/to/action` | Chemin d’accès dans l’espace de travail extrait de l’exécuteur, par rapport au répertoire de travail par défaut (`${{ github.workspace }}`) | Cas edge uniquement | ```yaml on: [push] jobs: my_first_job: runs-on: ubuntu-latest steps: # References an action in the same repository at the running commit - uses: $/.github/actions/hello-world-action ``` ### Exemple : Utilisation d’une action dans le même dépôt que le workflow `./path/to/dir` Chemin du répertoire qui contient l’action dans le dépôt de votre workflow. Vous devez extraire votre référentiel avant d’utiliser l’action et le `./` chemin d’accès est résolu par rapport à l’espace de travail de l’exécuteur plutôt qu’au référentiel du flux de travail en cours d’exécution. Pour la plupart des cas, utilisez plutôt la `$/` syntaxe indiquée ci-dessus. Exemple de structure de fichier de dépôt : ```shell |-- hello-world (repository) | |__ .github | └── workflows | └── my-first-workflow.yml | └── actions | |__ hello-world-action | └── action.yml ``` Le chemin d’accès relatif (`./`) par rapport au répertoire de travail par défaut (`github.workspace`, `$GITHUB_WORKSPACE`). Si l’action extrait le référentiel d’un emplacement différent du flux de travail, le chemin d’accès relatif utilisé pour les actions locales doit être mis à jour. Exemple de fichier de workflow : ```yaml jobs: my_first_job: runs-on: ubuntu-latest steps: # This step checks out a copy of your repository. - name: My first step - check out repository uses: actions/checkout@v6 # This step references the directory that contains the action. - name: Use local hello-world-action uses: ./.github/actions/hello-world-action ``` ### Exemple : Utilisation d’une action de Docker Hub `docker://{image}:{tag}` Image Docker publiée sur [Docker Hub](https://hub.docker.com/). ```yaml jobs: my_first_job: steps: - name: My first step uses: docker://alpine:3.8 ``` ### Exemple : Utilisation d’une action de registre public Docker `docker://{host}/{image}:{tag}` Image Docker dans un registre public. Cet exemple utilise Google Container Registry à l’adresse `gcr.io`. ```yaml jobs: my_first_job: steps: - name: My first step uses: docker://gcr.io/cloud-builders/gradle ``` ### Exemple : Utilisation d’une action à l’intérieur d’un autre dépôt privé que le workflow Si l’action se trouve dans un référentiel interne ou dans un référentiel privé configuré pour autoriser l’accès à partir du référentiel de votre workflow, vous pouvez référencer l’action directement. Pour plus d’informations, consultez [Gestion des paramètres de GitHub Actions pour un référentiel](/fr/enterprise-server@3.22/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-an-internal-repository) et [Gestion des paramètres de GitHub Actions pour un référentiel](/fr/enterprise-server@3.22/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#allowing-access-to-components-in-a-private-repository). Si l’action n’est pas dans un référentiel configuré pour autoriser l’accès, vous devez extraire le référentiel et référencer l’action localement. Générez un personal access token et ajoutez le jeton en tant qu'un secret. L’exemple suivant montre cette méthode pour référencer une action. Pour plus d’informations, consultez « [Gestion de vos jetons d’accès personnels](/fr/enterprise-server@3.22/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) » et « [Utilisation de secrets dans GitHub Actions](/fr/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets) ». Remplacez `PERSONAL_ACCESS_TOKEN` dans l’exemple par le nom de votre secret. ```yaml jobs: my_first_job: steps: - name: Check out repository uses: actions/checkout@v6 with: repository: octocat/my-private-repo ref: v1.0 token: ${{ secrets.PERSONAL_ACCESS_TOKEN }} path: ./.github/actions/my-private-repo - name: Run my action uses: ./.github/actions/my-private-repo/my-action ``` Vous pouvez également utiliser un GitHub App plutôt qu’un personal access token pour vous assurer que votre flux de travaux continue de fonctionner même si le personal access token détenteur quitte. 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/enterprise-server@3.22/apps/creating-github-apps/authenticating-with-a-github-app/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow) ». ## `jobs..steps[*].run` Exécute des programmes en ligne de commande qui ne dépassent pas 21 000 caractères à l’aide de l’interpréteur de commandes du système d’exploitation. Si vous ne fournissez pas d’élément `name`, le nom de l’étape est défini par défaut sur le texte spécifié dans la commande `run`. Par défaut, les commandes s’exécutent à l’aide d’interpréteurs de commandes sans connexion. Vous pouvez choisir un autre interpréteur de commandes et personnaliser l’interpréteur de commandes utilisé pour exécuter des commandes. Pour plus d’informations, consultez [`jobs..steps[*].shell`](#jobsjob_idstepsshell). Chaque mot clé `run` représente un nouveau processus et un nouvel interpréteur de commandes dans l’environnement de l’exécuteur. Lorsque vous fournissez des commandes qui s’étendent sur plusieurs lignes, chaque ligne s’exécute dans le même interpréteur de commandes. Par exemple : * Commande sur une seule ligne : ```yaml - name: Install Dependencies run: npm install ``` * Commande sur plusieurs lignes : ```yaml - name: Clean install dependencies and build run: | npm ci npm run build ``` ## `jobs..steps[*].working-directory` À l’aide du mot clé `working-directory`, vous pouvez spécifier le répertoire de travail d’où exécuter la commande. ```yaml - name: Clean temp directory run: rm -rf * working-directory: ./temp ``` Vous pouvez également spécifier un répertoire de travail par défaut pour toutes les étapes `run` d'un projet ou pour toutes les étapes `run` de l'ensemble du flux de travail. Pour plus d’informations, consultez [`defaults.run.working-directory`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#defaultsrunworking-directory) et [`jobs..defaults.run.working-directory`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iddefaultsrunworking-directory). Vous pouvez également utiliser une étape `run` pour exécuter un script. Pour plus d’informations, consultez « [Ajout de scripts à votre workflow](/fr/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/add-scripts) ». ## `jobs..steps[*].shell` Vous pouvez remplacer les paramètres d’interpréteur de commandes par défaut dans le système d’exploitation de l’exécuteur ainsi que les paramètres par défaut du travail à l’aide du mot clé `shell`. Vous pouvez utiliser des mots clés `shell` intégrés ou définir un ensemble personnalisé d’options d’interpréteur de commandes. La commande d’interpréteur de commandes exécutée en interne exécute un fichier temporaire qui contient les commandes spécifiées dans le mot clé `run`. | Plateforme prise en charge | Paramètre `shell` | Description | Commande exécutée en interne | | -------------------------- | ----------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- | | Linux / macOS | unspecified | Interpréteur de commandes par défaut sur les plateformes non Windows. Notez que cette opération exécute une commande différente par rapport à quand `bash` est spécifié explicitement. Si `bash` n’est pas trouvé dans le chemin, il est considéré comme `sh`. | `bash -e {0}` | | Tous | `bash` | Interpréteur de commandes par défaut sur les plateformes non Windows avec `sh` comme valeur de secours. Lors de la spécification d’un interpréteur de commandes Bash sur Windows, l’interpréteur de commandes Bash inclus avec Git pour Windows est utilisé. | `bash --noprofile --norc -eo pipefail {0}` | | Tous | `pwsh` | PowerShell Core. GitHub ajoute l’extension `.ps1` au nom de votre script. | `pwsh -command ". '{0}'"` | | Tous | `python` | Exécute la commande Python. | `python {0}` | | Linux / macOS | `sh` | Comportement de secours pour les plateformes non Windows si aucun interpréteur de commandes n’est fourni et que `bash` ne se trouve pas dans le chemin. | `sh -e {0}` | | Windows | `cmd` | GitHub ajoute l’extension `.cmd` au nom de votre script et se substitue à `{0}`. | `%ComSpec% /D /E:ON /V:OFF /S /C "CALL "{0}""`. | | Windows | `pwsh` | Il s’agit de l’interpréteur de commandes par défaut utilisé sur Windows. PowerShell Core. GitHub ajoute l’extension `.ps1` au nom de votre script. Si *PowerShell Core* n’est pas installé sur votre exécuteur Windows auto-hébergé, *PowerShell Desktop* est utilisé à la place. | `pwsh -command ". '{0}'"`. | | Windows | `powershell` | PowerShell Desktop. GitHub ajoute l’extension `.ps1` au nom de votre script. | `powershell -command ". '{0}'"`. | Vous pouvez également spécifier un shell par défaut pour toutes les étapes `run` d'un projet ou pour toutes les étapes `run` de l'ensemble du flux de travail. Pour plus d’informations, consultez [`defaults.run.shell`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#defaultsrunshell) et [`jobs..defaults.run.shell`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iddefaultsrunshell). ### Exemple : Exécution d’une commande à l’aide de Bash ```yaml steps: - name: Display the path shell: bash run: echo $PATH ``` ### Exemple : Exécution d’une commande à l’aide de Windows `cmd` ```yaml steps: - name: Display the path shell: cmd run: echo %PATH% ``` ### Exemple : Exécution d’une commande à l’aide de PowerShell Core ```yaml steps: - name: Display the path shell: pwsh run: echo ${env:PATH} ``` ### Exemple : Utilisation de PowerShell Desktop pour exécuter une commande ```yaml steps: - name: Display the path shell: powershell run: echo ${env:PATH} ``` ### Exemple : Exécution d’un script Python inline ```yaml steps: - name: Display the path shell: python run: | import os print(os.environ['PATH']) ``` ### Interpréteur de commandes personnalisé Vous pouvez définir la valeur `shell` sur une chaîne de modèle à l’aide de `command [options] {0} [more_options]`. GitHub interprète le premier mot délimité par des espaces blancs de la chaîne en tant que commande et insère le nom de fichier pour le script temporaire à l’adresse `{0}`. Par exemple : ```yaml steps: - name: Display the environment variables and their values shell: perl {0} run: | print %ENV ``` La commande utilisée, `perl` dans cet exemple, doit être installée sur l’exécuteur. ### Codes de sortie et préférence d’action en cas d’erreur Pour les mots-clés de shell intégrés, nous fournissons les valeurs par défaut suivantes qui sont exécutées par les coureurs GitHub-hébergés par. Vous devez utiliser ces instructions lors de l’exécution de scripts de l’interpréteur de commandes. * `bash` / `sh`: * Par défaut, le comportement fail-fast est appliqué en utilisant `set -e` tant pour `sh` que pour `bash`. Lorsque `shell: bash` est spécifié, `-o pipefail` est également appliqué pour mettre en œuvre la sortie anticipée des pipelines qui génèrent un état de sortie différent de zéro. * Vous pouvez prendre le contrôle total des paramètres de l’interpréteur de commandes en fournissant une chaîne de modèle aux options de l’interpréteur de commandes. Par exemple : `bash {0}`. * Les interpréteurs de commandes de type `sh` se terminent par le code de sortie de la dernière commande exécutée dans un script, ce qui est également le comportement par défaut pour les actions. L’exécuteur signale l’état de l’étape en tant qu’échec/réussite en fonction de ce code de sortie. * `powershell`/`pwsh` * Comportement Fail-fast lorsque cela est possible. Pour l’interpréteur de commandes intégré `pwsh` et `powershell`, nous allons ajouter `$ErrorActionPreference = 'stop'` au contenu du script. * Nous ajoutons `if ((Test-Path -LiteralPath variable:\LASTEXITCODE)) { exit $LASTEXITCODE }` aux scripts PowerShell afin que les états d’action reflètent le dernier code de sortie du script. * Les utilisateurs peuvent toujours choisir de ne pas utiliser l’interpréteur de commandes intégré et de fournir une option d’interpréteur de commandes personnalisée comme `pwsh -File {0}` ou `powershell -Command "& '{0}'"`, selon les besoins. * `cmd` * Il semble qu’il n’existe pas de moyen d’adopter entièrement un comportement Fail-fast autre que l’écriture de votre script pour vérifier chaque code d’erreur et répondre en conséquence. Étant donné que nous ne pouvons en fait pas fournir ce comportement par défaut, vous devez écrire ce comportement dans votre script. * `cmd.exe` s’arrête avec le niveau d’erreur du dernier programme qu’il a exécuté, et retourne le code d’erreur à l’exécuteur. Ce comportement est cohérent en interne avec le comportement par défaut précédent de `sh` et de `pwsh`, et c’est la valeur par défaut de `cmd.exe`. Ce comportement reste donc intact. ## `jobs..steps[*].with` Mappage (`map`) des paramètres d’entrée définis par l’action. Chaque paramètre d’entrée est une paire clé/valeur. Les paramètres d’entrée sont définis en tant que variables d’environnement. La variable est dotée du préfixe `INPUT_` et est convertie en majuscules. Les paramètres d’entrée définis pour un conteneur Docker doivent utiliser `args`. Pour plus d’informations, consultez [`jobs..steps[*].with.args`](#jobsjob_idstepswithargs). ### Exemple de `jobs..steps[*].with` Définit les trois paramètres d’entrée (`first_name`, `middle_name` et `last_name`) définis par l’action `hello_world`. Ces variables d’entrée seront accessibles à l’action `hello-world` en tant que variables d’environnement `INPUT_FIRST_NAME`, `INPUT_MIDDLE_NAME` et `INPUT_LAST_NAME`. ```yaml jobs: my_first_job: steps: - name: My first step uses: actions/hello_world@main with: first_name: Mona middle_name: The last_name: Octocat ``` ## `jobs..steps[*].with.args` Une valeur `string` définit les entrées d’un conteneur Docker. GitHub passe le `args` au `ENTRYPOINT` du conteneur lors du démarrage de celui-ci. Un `array of strings` n’est pas pris en charge par ce paramètre. Un argument unique qui inclut des espaces doit être entouré de guillemets doubles `""`. ### Exemple de `jobs..steps[*].with.args` ```yaml steps: - name: Explain why this job ran uses: octo-org/action-name@main with: entrypoint: /bin/echo args: The ${{ github.event_name }} event triggered this step. ``` Les valeurs `args` sont utilisées à la place de l’instruction `CMD` dans un `Dockerfile`. Si vous utilisez `CMD` dans votre `Dockerfile`, utilisez les instructions classées par ordre de préférence : 1. Documentez les arguments requis dans le fichier README de l’action et omettez-les de l’instruction `CMD`. 2. Utilisez les valeurs par défaut qui autorisent l’utilisation de l’action sans spécifier aucune valeur `args`. 3. Si l’action expose un indicateur `--help`, ou quelque chose de similaire, utilisez-le comme valeur par défaut pour rendre votre action auto-documentée. ## `jobs..steps[*].with.entrypoint` Remplace la valeur `ENTRYPOINT` Docker dans le `Dockerfile`, ou la définit si aucune n’est encore spécifiée. Contrairement à l’instruction Docker `ENTRYPOINT` qui a un interpréteur de commandes et le format exec, le mot clé `entrypoint` accepte une seule chaîne définissant l’exécutable à exécuter. ### Exemple de `jobs..steps[*].with.entrypoint` ```yaml steps: - name: Run a custom command uses: octo-org/action-name@main with: entrypoint: /a/different/executable ``` Le mot clé `entrypoint` est destiné à être utilisé avec des actions de conteneur Docker, mais vous pouvez également l’utiliser avec des actions JavaScript qui ne définissent aucune entrée. ## `jobs..steps[*].env` Définit des variables pour les étapes à utiliser dans l’environnement de l’exécuteur. Vous pouvez également définir des variables pour l’ensemble du workflow ou pour un travail. Pour plus d’informations, consultez [`env`](#env) et [`jobs..env`](#jobsjob_idenv). Quand plusieurs variables d’environnement sont définies avec le même nom, GitHub utilise la variable la plus spécifique. Par exemple, une variable d’environnement définie dans une étape remplace les variables d’environnement du travail et du workflow portant le même nom, pendant l’exécution de l’étape. Une variable d’environnement définie pour un travail remplace une variable de workflow de même nom, pendant l’exécution du travail. Les actions publiques peuvent spécifier les variables attendues dans le fichier README. Si vous définissez un secret ou une valeur sensible, comme un mot de passe ou un jeton, vous devez définir des secrets à l’aide du contexte `secrets`. Pour plus d’informations, consultez « [Référence des contextes](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts) ». ### Exemple de `jobs..steps[*].env` ```yaml steps: - name: My first action env: GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} FIRST_NAME: Mona LAST_NAME: Octocat ``` ## `jobs..steps[*].continue-on-error` Empêche que l’échec d’une étape fasse échouer un travail. Définissez la valeur `true` pour permettre à un travail de réussir en cas d’échec de cette étape. ## `jobs..steps[*].timeout-minutes` Nombre maximal de minutes pour exécuter l’étape avant l’arrêt du processus. Maximum : 360 pour les coureurs hébergés par GitHub- et les coureurs auto-hébergés. Les valeurs fractionnaires ne sont pas prises en charge. `timeout-minutes` doit être un entier positif. ## `jobs..timeout-minutes` Nombre maximal de minutes pendant lesquelles un travail peut s'exécuter avant que GitHub ne l'annule automatiquement. Valeur par défaut : 360 Si le délai d’expiration dépasse le délai d’exécution du travail pour l’exécuteur, le travail est annulé lorsque le délai d’exécution est écoulé à la place. Pour plus d’informations sur les limites de temps d’exécution des tâches, consultez [Facturation et utilisation](/fr/enterprise-server@3.22/actions/concepts/billing-and-usage#usage-limits-and-policy) pour GitHub- les coureurs hébergés par [Limites d’Actions](/fr/enterprise-server@3.22/actions/reference/limits) pour les limites d’utilisation des coureurs auto-hébergés. > \[!NOTE] > Le `GITHUB_TOKEN` expire à la fin d’un travail ou après un délai maximal de 24 heures. Pour les coureurs auto-hébergés, le jeton peut constituer le facteur limitant si le délai d’exécution de la tâche dépasse 24 heures. Pour plus d’informations sur `GITHUB_TOKEN`, consultez « [Utiliser GITHUB\_TOKEN pour l’authentification dans les flux de travail](/fr/enterprise-server@3.22/actions/tutorials/authenticate-with-github_token) ». ## `jobs..strategy` Utilisez `jobs..strategy` pour utiliser une stratégie de matrice pour vos travaux. Une stratégie de matrice vous permet d’utiliser des variables dans une définition de travail unique pour créer automatiquement plusieurs exécutions de travaux basées sur les combinaisons des variables. Par exemple, vous pouvez utiliser une stratégie de matrice pour tester votre code dans plusieurs versions d’un langage ou sur plusieurs systèmes d’exploitation. Pour plus d’informations, consultez [Exécution de variantes de tâches dans un workflow](/fr/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/run-job-variations). ## `jobs..strategy.matrix` Utilisez `jobs..strategy.matrix` pour définir une matrice de différentes configurations de travail. Pour plus d’informations, consultez « [Exécution de variantes de tâches dans un workflow](/fr/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/run-job-variations) ». Une matrice génère au maximum 256 travaux par exécution de workflow. Cette limite s’applique aux coureurs hébergés par GitHub- ainsi qu’aux coureurs auto-hébergés. Les variables que vous définissez deviennent des propriétés dans le contexte `matrix`. Vous pouvez référencer la propriété dans d’autres zones de votre fichier de workflow. Dans cet exemple, vous pouvez utiliser `matrix.version` et `matrix.os` pour accéder aux valeurs actuelles de `version` et `os` utilisées par le travail. Pour plus d’informations, consultez « [Référence des contextes](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts) ». Par défaut, GitHub maximisera le nombre de travaux exécutés en parallèle en fonction de la disponibilité de l’exécutant. L’ordre des variables dans la matrice détermine l’ordre dans lequel les travaux sont créés. La première variable que vous définissez est le premier travail créé dans votre exécution de workflow. ### Utilisation d’une matrice à une seule dimension Le workflow suivant définit la variable `version` avec les valeurs `[10, 12, 14]`. Le workflow exécute trois travaux, un pour chaque valeur de la variable. Chaque travail accède à la valeur `version` via le contexte `matrix.version`, et passe la valeur en tant que `node-version` à l’action `actions/setup-node`. ```yaml jobs: example_matrix: strategy: matrix: version: [10, 12, 14] steps: - uses: actions/setup-node@v7 with: node-version: ${{ matrix.version }} ``` ### Utilisation d’une matrice multidimensionnelle Spécifiez plusieurs variables pour créer une matrice multidimensionnelle. Une tâche sera exécutée pour chaque combinaison possible des variables. Par exemple, le workflow suivant spécifie deux variables : * Deux systèmes d’exploitation spécifiés dans la variable `os` * Trois versions de Node.js spécifiées dans la variable `version` Le workflow exécute six travaux, un pour chaque combinaison des variables `os` et `version`. Chaque travail affecte la valeur `runs-on` à la valeur `os` actuelle, et passe la valeur `version` actuelle à l’action `actions/setup-node`. ```yaml jobs: example_matrix: strategy: matrix: os: [ubuntu-22.04, ubuntu-24.04] version: [10, 12, 14] runs-on: ${{ matrix.os }} steps: - uses: actions/setup-node@v7 with: node-version: ${{ matrix.version }} ``` Une configuration de variable dans une matrice peut être un `array` de `object`s. Par exemple, la matrice suivante produit 4 travaux avec des contextes correspondants. ```yaml matrix: os: - ubuntu-latest - macos-latest node: - version: 14 - version: 20 env: NODE_OPTIONS=--openssl-legacy-provider ``` Chaque travail de la matrice aura sa propre combinaison de valeurs de `os` et de `node` , comme indiqué ci-dessous. ```yaml - matrix.os: ubuntu-latest matrix.node.version: 14 - matrix.os: ubuntu-latest matrix.node.version: 20 matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider - matrix.os: macos-latest matrix.node.version: 14 - matrix.os: macos-latest matrix.node.version: 20 matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider ``` ## `jobs..strategy.matrix.include` Pour chaque objet de la liste `include`, les paires clé:valeur dans l’objet sont ajoutées à chacune des combinaisons de matrices si aucune des paires clé:valeur ne remplace les valeurs de matrice d’origine. Si l’objet ne peut pas être ajouté à l’une des combinaisons de matrices, une nouvelle combinaison de matrices est créée à la place. Notez que les valeurs de matrice d’origine ne seront pas remplacées, mais que les valeurs de matrice ajoutées peuvent être remplacées. ### Exemple : Développement de configurations Par exemple, le workflow suivant exécute quatre tâches, un pour chaque combinaison de `os` et `node`. Lorsque le travail pour la valeur `os` de `windows-latest` et la valeur `node` de `16` s’exécute, une variable supplémentaire appelée `npm` avec la valeur `6` sera incluse dans le travail. ```yaml jobs: example_matrix: strategy: matrix: os: [windows-latest, ubuntu-latest] node: [14, 16] include: - os: windows-latest node: 16 npm: 6 runs-on: ${{ matrix.os }} steps: - uses: actions/setup-node@v7 with: node-version: ${{ matrix.node }} - if: ${{ matrix.npm }} run: npm install -g npm@${{ matrix.npm }} - run: npm --version ``` ### Exemple : Ajout de configurations Par exemple, cette matrice exécutera 10 travaux, un pour chaque combinaison de `os` et `version` dans la matrice, plus un travail pour la valeur `os` de `windows-latest` et la valeur `version` de `17`. ```yaml jobs: example_matrix: strategy: matrix: os: [macos-latest, windows-latest, ubuntu-latest] version: [12, 14, 16] include: - os: windows-latest version: 17 ``` Si vous ne spécifiez aucune variable de matrice, toutes les configurations sous `include` sont exécutées. Par exemple, le workflow suivant exécuterait deux travaux, un pour chaque entrée `include`. Cela vous permet de tirer parti de la stratégie de matrice sans avoir une matrice entièrement remplie. ```yaml jobs: includes_only: runs-on: ubuntu-latest strategy: matrix: include: - site: "production" datacenter: "site-a" - site: "staging" datacenter: "site-b" ``` ## `jobs..strategy.matrix.exclude` Une configuration exclue a seulement besoin d’être une correspondance partielle pour être exclue. `include` Toutes les combinaisons sont traitées après `exclude`. Cela vous permet d’utiliser `include` pour rajouter des combinaisons qui ont été précédemment exclues. ## `jobs..strategy.fail-fast` Vous pouvez contrôler la façon dont les échecs de travaux sont gérés avec `jobs..strategy.fail-fast` et `jobs..continue-on-error`. `jobs..strategy.fail-fast` s’applique à l’ensemble de la matrice. Si `jobs..strategy.fail-fast` est défini sur `true`, ou son expression aboutit à `true`, GitHub annule tous les travaux en cours et en file d’attente dans la matrice en cas d’échec d’un des travaux de la matrice. Cette propriété a la valeur par défaut `true`. `jobs..continue-on-error` s’applique à un seul travail. Si `jobs..continue-on-error` a la valeur `true`, les autres travaux de la matrice continuent de s’exécuter même en cas d’échec du travail avec `jobs..continue-on-error: true`. Vous pouvez utiliser `jobs..strategy.fail-fast` et `jobs..continue-on-error` ensemble. Par exemple, le workflow suivant démarre quatre travaux. Pour chaque travail, `continue-on-error` est déterminé par la valeur de `matrix.experimental`. En cas d’échec de l’un des travaux avec `continue-on-error: false`, tous les travaux en cours ou en file d’attente sont annulés. En cas d’échec du travail avec `continue-on-error: true`, les autres travaux ne sont pas affectés. ```yaml jobs: test: runs-on: ubuntu-latest continue-on-error: ${{ matrix.experimental }} strategy: fail-fast: true matrix: version: [6, 7, 8] experimental: [false] include: - version: 9 experimental: true ``` ## `jobs..strategy.max-parallel` Par défaut, GitHub maximisera le nombre de travaux exécutés en parallèle en fonction de la disponibilité de l’exécutant. ## `jobs..continue-on-error` `jobs..continue-on-error` s’applique à un seul travail. Si `jobs..continue-on-error` a la valeur `true`, les autres travaux de la matrice continuent de s’exécuter même en cas d’échec du travail avec `jobs..continue-on-error: true`. Empêche que l’échec d’un travail fasse échouer une exécution de workflow. Définissez la valeur `true` pour permettre à un workflow de réussir en cas d’échec de ce travail. ### Exemple : Empêcher un job de matrice défaillant spécifique de compromettre l'exécution d'un workflow. Vous pouvez autoriser l’échec de travaux spécifiques d’une matrice de travaux sans faire échouer l’exécution du workflow. Par exemple, si vous souhaitiez autoriser uniquement l'échec d'un travail expérimental configuré avec `node` sur `15` sans compromettre l’exécution du workflow. ```yaml runs-on: ${{ matrix.os }} continue-on-error: ${{ matrix.experimental }} strategy: fail-fast: false matrix: node: [13, 14] os: [macos-latest, ubuntu-latest] experimental: [false] include: - node: 15 os: ubuntu-latest experimental: true ``` ## `jobs..container` > \[!NOTE] > Si vos flux de travail utilisent des actions de conteneurs Docker, des conteneurs de tâches ou des conteneurs de services, vous devez utiliser un programme d'exécution Linux : > > * Si vous utilisez des exécuteurs hébergés sur GitHub, vous devez utiliser un exécuteur Ubuntu. > * Si vous utilisez des exécuteurs autohébergés, vous devez utiliser une machine Linux en tant qu’exécuteur, et Docker doit être installé. Utilisez `jobs..container` pour créer un conteneur permettant d’exécuter les étapes d’un travail qui ne spécifient pas encore de conteneur. Si vous avez des étapes qui utilisent à la fois des actions de script et des actions de conteneur, les actions de conteneur s’exécutent en tant que conteneurs frères sur le même réseau avec les mêmes montages de volume. Si vous ne définissez pas de `container`, toutes les étapes s’exécutent directement sur l’hôte spécifié par `runs-on`, sauf si une étape fait référence à une action configurée pour s’exécuter dans un conteneur. > \[!NOTE] > L’interpréteur de commandes par défaut pour les étapes `run` incluses dans un conteneur est `sh` plutôt que `bash`. Vous pouvez le remplacer par [`jobs..defaults.run`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iddefaultsrun) ou [`jobs..steps[*].shell`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsshell). ### Exemple : Exécution d’un travail dans un conteneur ```yaml copy name: CI on: push: branches: [ main ] jobs: container-test-job: runs-on: ubuntu-latest container: image: node:18 env: NODE_ENV: development ports: - 80 volumes: - my_docker_volume:/volume_mount options: --cpus 1 steps: - name: Check for dockerenv file run: (ls /.dockerenv && echo Found dockerenv) || (echo No dockerenv) ``` Quand vous spécifiez uniquement une image conteneur, vous pouvez omettre le mot clé `image`. ```yaml jobs: container-test-job: runs-on: ubuntu-latest container: node:18 ``` ## `jobs..container.image` Utilisez `jobs..container.image` pour définir l’image Docker à utiliser en tant que conteneur afin d’exécuter l’action. La valeur peut être le nom de l’image Docker Hub ou un nom de registre. > \[!NOTE] > Docker Hub impose normalement des limites de débit sur les opérations d’envoi (push) et de tirage (pull), ce qui affectera les tâches sur les exécuteurs auto-hébergés. Toutefois, les exécuteurs hébergés par GitHub ne sont pas soumis à ces limites, conformément à un accord entre GitHub et Docker. ## `jobs..container.credentials` Si le registre de conteneurs de l’image nécessite une authentification pour tirer l’image, vous pouvez utiliser `jobs..container.credentials` pour définir un `map` de `username` et de `password`. Les informations d’identification correspondent aux mêmes valeurs que celles que vous fournissez à la commande [`docker login`](https://docs.docker.com/engine/reference/commandline/login/). ### Exemple : Définition des informations d’identification d’un registre de conteneurs ```yaml container: image: ghcr.io/owner/image credentials: username: ${{ github.actor }} password: ${{ secrets.github_token }} ``` ## `jobs..container.env` Utilisez `jobs..container.env` pour définir un `map` de variables d’environnement dans le conteneur. ## `jobs..container.ports` Utilisez `jobs..container.ports` pour définir un `array` de ports à exposer sur le conteneur. ## `jobs..container.volumes` Utilisez `jobs..container.volumes` pour définir un `array` de volumes à utiliser par le conteneur. Vous pouvez utiliser des volumes pour partager des données entre des services ou d’autres étapes d’un travail. Vous pouvez spécifier des volumes Docker nommés, des volumes Docker anonymes ou des montages de liaisons sur l’hôte. Pour spécifier un volume, vous spécifiez le chemin source et le chemin de destination : `:`. La valeur `` est un nom de volume ou un chemin absolu sur la machine hôte et `` est un chemin absolu dans le conteneur. ### Exemple : Montage de volumes dans un conteneur ```yaml volumes: - my_docker_volume:/volume_mount - /data/my_data - /source/directory:/destination/directory ``` ## `jobs..container.options` Utilisez `jobs..container.options` pour configurer des options supplémentaires de ressources de conteneur Docker. Pour obtenir la liste des options, consultez « [Options `docker create`](https://docs.docker.com/engine/reference/commandline/create/#options) ». > \[!WARNING] > Les options `--network` et `--entrypoint` ne sont pas prises en charge. ## `jobs..services` > \[!NOTE] > Si vos flux de travail utilisent des actions de conteneurs Docker, des conteneurs de tâches ou des conteneurs de services, vous devez utiliser un programme d'exécution Linux : > > * Si vous utilisez des exécuteurs hébergés sur GitHub, vous devez utiliser un exécuteur Ubuntu. > * Si vous utilisez des exécuteurs autohébergés, vous devez utiliser une machine Linux en tant qu’exécuteur, et Docker doit être installé. Utilisé pour héberger des conteneurs de service pour une tâche dans un workflow. Les conteneurs de service sont utiles pour créer des bases de données ou des services de cache comme Redis. L’exécuteur crée automatiquement un réseau Docker et gère le cycle de vie des conteneurs de service. Si vous configurez votre travail pour qu’il s’exécute dans un conteneur ou que votre étape utilise des actions de conteneur, vous n’avez pas besoin de mapper les ports pour accéder au service ou à l’action. Docker expose automatiquement tous les ports entre les conteneurs se trouvant sur le même réseau de pont défini par l’utilisateur Docker. Vous pouvez référencer directement le conteneur de service par son nom d’hôte. Le nom d’hôte est automatiquement mappé au nom d’étiquette que vous configurez pour le service dans le workflow. Si vous configurez le travail pour qu’il s’exécute directement sur la machine de l’exécuteur et que votre étape n’utilise pas d’action de conteneur, vous devez mapper tous les ports de conteneur de service Docker requis à l’hôte Docker (la machine de l’exécuteur). Vous pouvez accéder au conteneur de service à l’aide de localhost et du port mappé. Pour plus d’informations sur les différences entre les conteneurs de service réseau, consultez « [Communication avec les conteneurs de service Docker](/fr/enterprise-server@3.22/actions/tutorials/use-containerized-services/use-docker-service-containers) ». ### Exemple : Utilisation de localhost Cet exemple crée deux services : nginx et redis. Lorsque vous spécifiez le port du conteneur, mais pas le port de l’hôte, le port du conteneur est attribué de manière aléatoire à un port libre sur l’hôte. GitHub définit le port hôte affecté dans le `${{job.services..ports}}` contexte. Dans cet exemple, vous pouvez accéder aux ports hôtes du service à l’aide des contextes `${{ job.services.nginx.ports['80'] }}` et `${{ job.services.redis.ports['6379'] }}`. ```yaml services: nginx: image: nginx # Map port 8080 on the Docker host to port 80 on the nginx container ports: - 8080:80 redis: image: redis # Map random free TCP port on Docker host to port 6379 on redis container ports: - 6379/tcp steps: - run: | echo "Redis available on 127.0.0.1:${{ job.services.redis.ports['6379'] }}" echo "Nginx available on 127.0.0.1:${{ job.services.nginx.ports['80'] }}" ``` ## `jobs..services..image` Image Docker à utiliser comme conteneur de service pour exécuter l’action. La valeur peut être le nom de l’image Docker Hub ou un nom de registre. Si `jobs..services..image` est une chaîne vide, le service ne démarre pas. Vous pouvez l’utiliser pour configurer des services conditionnels, comme dans l’exemple suivant. ```yaml services: nginx: image: ${{ options.nginx == true && 'nginx' || '' }} ``` ## `jobs..services..credentials` Si le registre de conteneurs de l’image nécessite une authentification pour tirer l’image, vous pouvez utiliser `jobs..container.credentials` pour définir un `map` de `username` et de `password`. Les informations d’identification correspondent aux mêmes valeurs que celles que vous fournissez à la commande [`docker login`](https://docs.docker.com/engine/reference/commandline/login/). ### Exemple de `jobs..services..credentials` ```yaml services: myservice1: image: ghcr.io/owner/myservice1 credentials: username: ${{ github.actor }} password: ${{ secrets.github_token }} myservice2: image: dockerhub_org/myservice2 credentials: username: ${{ secrets.DOCKER_USER }} password: ${{ secrets.DOCKER_PASSWORD }} ``` ## `jobs..services..env` Définit un ensemble (`map`) de variables d'environnement dans le conteneur de service. ## `jobs..services..ports` Spécifie un ensemble (`array`) de ports à exposer sur le conteneur de service. ## `jobs..services..volumes` Définit un tableau (`array`) de volumes pour le conteneur de service à utiliser. Vous pouvez utiliser des volumes pour partager des données entre des services ou d’autres étapes d’un travail. Vous pouvez spécifier des volumes Docker nommés, des volumes Docker anonymes ou des montages de liaisons sur l’hôte. Pour spécifier un volume, vous spécifiez le chemin source et le chemin de destination : `:`. La valeur `` est un nom de volume ou un chemin absolu sur la machine hôte et `` est un chemin absolu dans le conteneur. ### Exemple de `jobs..services..volumes` ```yaml volumes: - my_docker_volume:/volume_mount - /data/my_data - /source/directory:/destination/directory ``` ## `jobs..services..options` Options de ressources de conteneur Docker supplémentaires. Pour obtenir la liste des options, consultez « [Options `docker create`](https://docs.docker.com/engine/reference/commandline/create/#options) ». > \[!WARNING] > L'option `--network` n'est pas prise en charge. ## `jobs..uses` Emplacement et version d’un fichier de workflow réutilisable à exécuter en tant que travail. Utilisez l’une des syntaxes suivantes : * `$/.github/workflows/{filename}` pour un flux de travail réutilisable dans le même référentiel. Il s’agit de la syntaxe recommandée pour référencer un flux de travail réutilisable dans le même référentiel. Cette syntaxe n’est pas disponible dans GitHub Enterprise Server. * `{owner}/{repo}/.github/workflows/{filename}@{ref}` pour les workflows réutilisables dans les référentiels publics, internes et privés. * `./.github/workflows/{filename}` pour des workflows réutilisables dans le même dépôt. Lorsque vous référencez un flux de travail réutilisable avec `{owner}/{repo}` et `@{ref}`que vous `{ref}` pouvez être un sha, une balise de mise en production ou un nom de branche. Si une balise de mise en production et une branche portent le même nom, la balise de mise en production est prioritaire sur le nom de la branche. L’utilisation du SHA de validation est l’option la plus sûre pour la stabilité et la sécurité. Pour plus d’informations, consultez « [Informations de référence sur l’utilisation sécurisée](/fr/enterprise-server@3.22/actions/reference/security/secure-use#reusing-third-party-workflows) ». Lorsque vous référencez un flux de travail réutilisable dans le même référentiel à l’aide `$/` ou `./` (sans `{owner}/{repo}` et `@{ref}`), le flux de travail appelé provient de la même validation que le flux de travail de l’appelant. Une `$/` référence ne doit pas inclure de `@{ref}` suffixe et `$/` n’est pas disponible dans GitHub Enterprise Server. Les préfixes ref tels que `refs/heads` et `refs/tags` ne sont pas autorisés. Vous ne pouvez pas utiliser de contextes ou d’expressions dans ce mot clé. ### Exemple de `jobs..uses` ```yaml jobs: call-workflow-1-in-local-repo: uses: octo-org/this-repo/.github/workflows/workflow-1.yml@172239021f7ba04fe7327647b213799853a9eb89 call-workflow-2-in-local-repo: uses: ./.github/workflows/workflow-2.yml # The `$/` syntax is not available in GitHub Enterprise Server. call-workflow-in-same-repo-at-running-commit: uses: $/.github/workflows/workflow-2.yml call-workflow-in-another-repo: uses: octo-org/another-repo/.github/workflows/workflow.yml@v1 ``` Pour plus d’informations, consultez « [Réutiliser des workflows](/fr/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows) ». ## `jobs..with` Lorsqu’un travail est utilisé pour appeler un workflow réutilisable, vous pouvez utiliser `with` pour fournir un mappage d’entrées qui sont passées au workflow appelé. Toutes les entrées que vous passez doivent correspondre aux spécifications d’entrée définies dans le workflow appelé. Contrairement à [`jobs..steps[*].with`](#jobsjob_idstepswith), les entrées que vous passez avec `jobs..with` sont non disponibles en tant que variables d’environnement dans le workflow appelé. Au lieu de cela, vous pouvez référencer les entrées à l’aide du contexte `inputs`. ### Exemple de `jobs..with` ```yaml jobs: call-workflow: uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main with: username: mona ``` ## `jobs..with.` Paire composée d’un identificateur de chaîne pour l’entrée et de la valeur de l’entrée. L’identificateur doit correspondre au nom d’une entrée définie par [`on.workflow_call.inputs.`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/metadata-syntax#inputsinput_id) dans le workflow appelé. Le type de données de la valeur doit correspondre au type défini par [`on.workflow_call.inputs..type`](#onworkflow_callinputsinput_idtype) dans le workflow appelé. Contextes d’expression autorisés : `github` et `needs`. ## `jobs..secrets` Lorsqu’un travail est utilisé pour appeler un workflow réutilisable, vous pouvez utiliser `secrets` pour fournir un mappage de secrets qui sont passés au workflow appelé. Les secrets que vous passez doivent correspondre aux noms définis dans le workflow appelé. ### Exemple de `jobs..secrets` ```yaml jobs: call-workflow: uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main secrets: access-token: ${{ secrets.PERSONAL_ACCESS_TOKEN }} ``` ## `jobs..secrets.inherit` Utilisez le mot clé `inherit` pour passer tous les secrets du workflow appelant au workflow appelé. Sont inclus tous les secrets auxquels le workflow appelant a accès, notamment les secrets de l’organisation, des dépôts et de l’environnement. Le mot clé `inherit` peut être utilisé pour passer des secrets entre des dépôts au sein de la même organisation ou entre des organisations au sein de la même entreprise. ### Exemple de `jobs..secrets.inherit` ```yaml on: workflow_dispatch: jobs: pass-secrets-to-workflow: uses: ./.github/workflows/called-workflow.yml secrets: inherit ``` ```yaml on: workflow_call: jobs: pass-secret-to-action: runs-on: ubuntu-latest steps: - name: Use a repo or org secret from the calling workflow. run: echo ${{ secrets.CALLING_WORKFLOW_SECRET }} ``` ## `jobs..secrets.` Paire composée d'un identificateur de type chaîne pour le secret et de sa valeur. L’identificateur doit correspondre au nom d’un secret défini par [`on.workflow_call.secrets.`](#onworkflow_callsecretssecret_id) dans le workflow appelé. Contextes d’expression autorisés : `github`, `needs` et `secrets`. ## Aide-mémoire de modèle de filtre Vous pouvez utiliser des caractères spéciaux dans les filtres de chemin, de branche et d’étiquette. * `*` : correspond à zéro caractère ou plus, mais ne correspond pas au caractère `/`. Par exemples, `Octo*` correspond à `Octocat`. * `**` : correspond à zéro caractère, quel qu’il soit, ou plus. * `?` : correspond à zéro caractère ou à l’un des caractères précédents. * `+` : correspond à l’un des caractères précédents, ou plus. * `[]` : correspond à un caractère alphanumérique indiqué entre crochets ou inclus dans des plages. Les plages ne peuvent inclure `a-z`, `A-Z` et `0-9`. Par exemple, la plage `[0-9a-z]` correspond à n’importe quel chiffre ou lettre minuscule. Par exemple, `[CB]at` correspond à `Cat` ou à `Bat`, et `[1-2]00` correspond à `100` et à `200`. * `!` : Placé au début d'un modèle, cela inverse les modèles positifs précédents. Il n’a pas de signification spéciale si ce n’est pas le premier caractère. Les caractères `*`, `[` et `!` sont des caractères spéciaux dans YAML. Si vous commencez un modèle avec `*`, `[` ou `!`, vous devez placer ce modèle entre guillemets. En outre, si vous utilisez une [séquence de flux](https://yaml.org/spec/1.2.2/#flow-sequences) avec un modèle contenant `[` et/ou `]`, le modèle doit être placé entre guillemets. ```yaml # Valid paths: - '**/README.md' # Invalid - creates a parse error that # prevents your workflow from running. paths: - **/README.md # Valid branches: [ main, 'release/v[0-9].[0-9]' ] # Invalid - creates a parse error branches: [ main, release/v[0-9].[0-9] ] ``` Pour plus d’informations sur la syntaxe des filtres de branche, d’étiquette et de chemin, consultez « [`on..`](#onpushbranchestagsbranches-ignoretags-ignore) », « [`on..`](#onpull_requestpull_request_targetbranchesbranches-ignore) » et « [`on..paths`](#onpushpull_requestpull_request_targetpathspaths-ignore) ». ### Modèles pour établir une correspondance avec des branches et des étiquettes | Modèle | Description | Exemples de correspondances | | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------- | | `feature/*` | Le caractère générique `*` correspond à n’importe quel caractère, mais ne correspond pas à la barre oblique (`/`). | `feature/my-branch`

`feature/your-branch` | | `feature/**` | Le caractère générique `**` correspond à n’importe quel caractère, y compris la barre oblique (`/`), dans les noms de branche et d’étiquette. | `feature/beta-a/my-branch`

`feature/your-branch`

`feature/mona/the/octocat` | | `main`

`releases/mona-the-octocat` | Correspond au nom exact d’une branche ou d’une étiquette. | `main`

`releases/mona-the-octocat` | | `'*'` | Correspond à tous les noms de branche et d’étiquette qui ne contiennent pas de barre oblique (`/`). Le caractère `*` est un caractère spécial dans YAML. Lorsque vous commencez un modèle par `*`, vous devez utiliser des guillemets. | `main`

`releases` | | `'**'` | Correspond à tous les noms de branche et d’étiquette. Il s’agit du comportement par défaut lorsque vous n’utilisez pas de filtre `branches` ou `tags`. | `all/the/branches`

`every/tag` | | `'*feature'` | Le caractère `*` est un caractère spécial dans YAML. Lorsque vous commencez un modèle par `*`, vous devez utiliser des guillemets. | `mona-feature`

`feature`

`ver-10-feature` | | `v2*` | Correspond aux noms de branche et d’étiquette qui commencent par `v2`. | `v2`

`v2.0`

`v2.9` | | `v[12].[0-9]+.[0-9]+` | Correspond à toutes les branches et balises de versionnage sémantique avec la version majeure 1 ou 2. | `v1.10.1`

`v2.0.0` | ### Modèles pour établir une correspondance avec des chemins de fichiers Les modèles de chemin doivent correspondre au chemin complet et commencer à la racine du dépôt. | Modèle | Description des correspondances | Exemples de correspondances | | ------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | `'*'` | Le caractère générique `*` correspond à n’importe quel caractère, mais ne correspond pas à la barre oblique (`/`). Le caractère `*` est un caractère spécial dans YAML. Lorsque vous commencez un modèle par `*`, vous devez utiliser des guillemets. | `README.md`

`server.rb` | | `'*.jsx?'` | Le caractère `?` correspond à zéro caractère ou à l’un des caractères précédents. | `page.js`

`page.jsx` | | `'**'` | Le caractère générique `**` correspond à n’importe quel caractère, y compris la barre oblique (`/`). Il s’agit du comportement par défaut lorsque vous n’utilisez pas de filtre `path`. | `all/the/files.md` | | `'*.js'` | Le caractère générique `*` correspond à n’importe quel caractère, mais ne correspond pas à la barre oblique (`/`). Correspond à tous les fichiers `.js` se trouvant à la racine du dépôt. | `app.js`

`index.js` | | `'**.js'` | Correspond à tous les fichiers `.js` se trouvant dans le dépôt. | `index.js`

`js/index.js`

`src/js/app.js` | | `docs/*` | Tous les fichiers se trouvant à la racine du répertoire `docs` uniquement, à la racine du dépôt. | `docs/README.md`

`docs/file.txt` | | `docs/**` | Tous les fichiers du répertoire `docs` et de ses sous-répertoires à la racine du référentiel. | `docs/README.md`

`docs/mona/octocat.txt` | | `docs/**/*.md` | Fichier avec un suffixe `.md` n’importe où dans le répertoire `docs`. | `docs/README.md`

`docs/mona/hello-world.md`

`docs/a/markdown/file.md` | | `'**/docs/**'` | Tout fichier se trouvant dans un répertoire `docs` n’importe où dans le dépôt. | `docs/hello.md`

`dir/docs/my-file.txt`

`space/docs/plan/space.doc` | | `'**/README.md'` | Fichier README.md n’importe où dans le dépôt. | `README.md`

`js/README.md` | | `'**/*src/**'` | Tout fichier d’un dossier avec un suffixe `src` n’importe où dans le dépôt. | `a/src/app.js`

`my-src/code/js/app.js` | | `'**/*-post.md'` | Fichier avec le suffixe `-post.md` n’importe où dans le dépôt. | `my-post.md`

`path/their-post.md` | | `'**/migrate-*.sql'` | Fichier avec le préfixe `migrate-` et le suffixe `.sql` n’importe où dans le dépôt. | `migrate-10909.sql`

`db/migrate-v1.0.sql`

`db/sept/migrate-v1.sql` | | `'*.md'`

`'!README.md'` | L’utilisation d’un point d’exclamation (`!`) devant un modèle le neutralise. Lorsqu’un fichier correspond à un modèle et qu’il correspond également à un modèle négatif défini ultérieurement dans le fichier, ce fichier n’est pas inclus. | `hello.md`

| | *Ne correspond pas à*

`README.md`

`docs/hello.md` | | | | `'*.md'`

`'!README.md'`

`README*` | Les modèles sont vérifiés de manière séquentielle. Un modèle qui neutralise un modèle précédent inclut à nouveau les chemins de fichier. | `hello.md`

`README.md`

`README.doc` |