# Référence des contextes Trouvez des informations sur les contextes disponibles dans GitHub Actions les flux de travail, notamment les propriétés disponibles, les méthodes d’accès et les exemples d’utilisation. ## Contextes disponibles | Nom du contexte | Type | Description | | --------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `github` | `object` | Informations sur l’exécution du workflow. Pour plus d’informations, voir Contexte [`github`](#github-context). | | `env` | `object` | Contient des variables définies dans un workflow, un travail ou une étape. Pour plus d’informations, voir Contexte [`env`](#env-context). | | `vars` | `object` | Contient les variables définies au niveau du dépôt, de l’organisation ou de l’environnement. Pour plus d’informations, voir Contexte [`vars`](#vars-context). | | `job` | `object` | Informations sur le travail en cours d’exécution. Pour plus d’informations, voir Contexte [`job`](#job-context). | | `jobs` | `object` | Pour les workflows réutilisables uniquement, contient les sorties des travaux du workflow réutilisable. Pour plus d’informations, voir Contexte [`jobs`](#jobs-context). | | `steps` | `object` | Informations sur les étapes qui ont été exécutées dans le travail en cours. Pour plus d’informations, voir Contexte [`steps`](#steps-context). | | `runner` | `object` | Informations sur l’exécuteur qui exécute le travail en cours. Pour plus d’informations, voir Contexte [`runner`](#runner-context). | | `secrets` | `object` | Contient les noms et valeurs des secrets disponibles pour une exécution de workflow. Pour plus d’informations, voir Contexte [`secrets`](#secrets-context). | | `strategy` | `object` | Informations sur la stratégie d’exécution de matrice pour le travail en cours. Pour plus d’informations, voir Contexte [`strategy`](#strategy-context). | | `matrix` | `object` | Contient les propriétés de matrice définies dans le workflow qui s’appliquent au travail en cours. Pour plus d’informations, voir Contexte [`matrix`](#matrix-context). | | `needs` | `object` | Contient les sorties de tous les travaux définis comme dépendance du travail en cours. Pour plus d’informations, voir Contexte [`needs`](#needs-context). | | `inputs` | `object` | Contient les entrées d’un workflow réutilisable ou déclenché manuellement. Pour plus d’informations, voir Contexte [`inputs`](#inputs-context). | Dans le cadre d’une expression, vous pouvez accéder aux informations de contexte à l’aide d’une syntaxe parmi deux syntaxes au choix. * Syntaxe d’index : `github['sha']` * Syntaxe de déréférencement de propriété : `github.sha` Pour permettre l’utilisation de la syntaxe de déréférencement de propriété, le nom de propriété doit commencer par une lettre ou `_`, et contenir uniquement des caractères alphanumériques, `-` ou `_`. Si vous tentez de déréférencer une propriété inexistante, cela aboutit à une chaîne vide. ### Déterminer quand utiliser des contextes GitHub Actions inclut une collection de variables *appelées contextes* et une collection similaire de *variables appelées variables par défaut*. Ces variables sont destinées à être utilisées à différents stades du workflow. * **Variables d’environnement par défaut :** ces variables d’environnement existent uniquement sur l’exécuteur du travail. Pour plus d’informations, consultez « [Références des variables](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/variables) ». * **Contextes :** vous pouvez utiliser la plupart des contextes à n’importe quel stade du workflow, notamment quand les *variables par défaut* ne sont pas disponibles. Par exemple, vous pouvez utiliser des contextes avec des expressions pour effectuer un traitement initial avant que le travail soit routé vers un exécuteur. Cela vous permet d’utiliser un contexte avec le mot clé conditionnel `if` pour déterminer si une étape doit être exécutée. Une fois le travail en cours d’exécution, vous pouvez également récupérer des variables de contexte à partir de l’exécuteur du travail, par exemple `runner.os`. Pour plus d’informations sur l’emplacement où vous pouvez utiliser divers contextes au sein d’un workflow, consultez [Disponibilité du contexte](#context-availability). L’exemple suivant montre comment ces différents types de variables peuvent être utilisés ensemble dans un travail : ```yaml copy name: CI on: push jobs: prod-check: if: ${{ github.ref == 'refs/heads/main' }} runs-on: ubuntu-latest steps: - run: echo "Deploying to production server on branch $GITHUB_REF" ``` Dans cet exemple, l’instruction `if` vérifie le contexte [`github.ref`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/contexts#github-context) pour déterminer le nom de la branche actuelle. Si le nom est `refs/heads/main`, les étapes suivantes sont exécutées. La `if` vérification est traitée par GitHub Actions, et le travail est envoyé uniquement à l’exécuteur si le résultat est `true`. Une fois le travail envoyé à l’exécuteur, l’étape est exécutée et référence la variable [`$GITHUB_REF`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/variables) de l’exécuteur. ### Disponibilité du contexte Différents contextes sont disponibles tout au long d’une exécution de workflow. Par exemple, le contexte `secrets` peut uniquement être utilisé à certains endroits au sein d’un travail. De plus, certaines fonctions peuvent uniquement être utilisées à certains endroits. Par exemple, la fonction `hashFiles` n’est pas disponible partout. Le tableau suivant répertorie les restrictions sur l’utilisation de chaque contexte et chaque fonction spéciale dans un workflow. Les contextes répertoriés sont disponibles uniquement pour la clé de workflow spécifiée et ne peuvent pas être utilisés ailleurs. Si elle n’est pas listée ci-dessous, une fonction peut être utilisée n’importe où. | Clé de workflow | Contexte | Fonctions spéciales | | -------------------------------------------------- | --------------------------------------------------------------------------------- | ------------------------------------------------ | | `run-name` | `github, inputs, vars` | None | | `concurrency` | `github, inputs, vars` | None | | `env` | `github, secrets, inputs, vars` | None | | `jobs..concurrency` | `github, needs, strategy, matrix, inputs, vars` | None | | `jobs..container` | `github, needs, strategy, matrix, vars, inputs` | None | | `jobs..container.credentials` | `github, needs, strategy, matrix, env, vars, secrets, inputs` | None | | `jobs..container.env.` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, inputs` | None | | `jobs..container.image` | `github, needs, strategy, matrix, vars, inputs` | None | | `jobs..continue-on-error` | `github, needs, strategy, vars, matrix, inputs` | None | | `jobs..defaults.run` | `github, needs, strategy, matrix, env, vars, inputs` | None | | `jobs..env` | `github, needs, strategy, matrix, vars, secrets, inputs` | None | | `jobs..environment` | `github, needs, strategy, matrix, vars, inputs` | None | | `jobs..environment.url` | `github, needs, strategy, matrix, job, runner, env, vars, steps, inputs` | None | | `jobs..if` | `github, needs, vars, inputs` | `always, cancelled, success, failure` | | `jobs..name` | `github, needs, strategy, matrix, vars, inputs` | None | | `jobs..outputs.` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | None | | `jobs..runs-on` | `github, needs, strategy, matrix, vars, inputs` | None | | `jobs..secrets.` | `github, needs, strategy, matrix, secrets, inputs, vars` | None | | `jobs..services` | `github, needs, strategy, matrix, vars, inputs` | None | | `jobs..services..credentials` | `github, needs, strategy, matrix, env, vars, secrets, inputs` | None | | `jobs..services..env.` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, inputs` | None | | `jobs..steps.continue-on-error` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.env` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.if` | `github, needs, strategy, matrix, job, runner, env, vars, steps, inputs` | `always, cancelled, success, failure, hashFiles` | | `jobs..steps.name` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.run` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.timeout-minutes` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.with` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..steps.working-directory` | `github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs` | `hashFiles` | | `jobs..strategy` | `github, needs, vars, inputs` | None | | `jobs..timeout-minutes` | `github, needs, strategy, matrix, vars, inputs` | None | | `jobs..with.` | `github, needs, strategy, matrix, inputs, vars` | None | | `on.workflow_call.inputs..default` | `github, inputs, vars` | None | | `on.workflow_call.outputs..value` | `github, jobs, vars, inputs` | None | ### Exemple : impression d’informations de contexte dans le journal Vous pouvez imprimer le contenu des contextes dans le journal pour le débogage. La fonction [`toJSON`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/expressions#tojson) est nécessaire pour l’impression élégante des objets JSON dans le journal. > \[!WARNING] > Lorsque vous utilisez le contexte `github` entier, n’oubliez pas qu’il inclut des informations sensibles telles que `github.token`. GitHub masque les secrets lorsqu’ils sont imprimés sur la console, mais vous devez être prudent lors de l’exportation ou de l’impression du contexte. ```yaml copy name: Context testing on: push jobs: dump_contexts_to_log: runs-on: ubuntu-latest steps: - name: Dump GitHub context env: GITHUB_CONTEXT: ${{ toJson(github) }} run: echo "$GITHUB_CONTEXT" - name: Dump job context env: JOB_CONTEXT: ${{ toJson(job) }} run: echo "$JOB_CONTEXT" - name: Dump steps context env: STEPS_CONTEXT: ${{ toJson(steps) }} run: echo "$STEPS_CONTEXT" - name: Dump runner context env: RUNNER_CONTEXT: ${{ toJson(runner) }} run: echo "$RUNNER_CONTEXT" - name: Dump strategy context env: STRATEGY_CONTEXT: ${{ toJson(strategy) }} run: echo "$STRATEGY_CONTEXT" - name: Dump matrix context env: MATRIX_CONTEXT: ${{ toJson(matrix) }} run: echo "$MATRIX_CONTEXT" ``` ## Contexte `github` Le contexte `github` contient des informations sur l’exécution du workflow et l’événement qui a déclenché cette exécution. Vous pouvez lire la plupart des données du contexte `github` dans les variables d’environnement. Pour plus d’informations sur les variables d’environnement, consultez [Stocker des informations dans des variables](/fr/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables). > \[!WARNING] > Lorsque vous utilisez le contexte `github` entier, n’oubliez pas qu’il inclut des informations sensibles telles que `github.token`. GitHub masque les secrets lorsqu’ils sont imprimés sur la console, mais vous devez être prudent lors de l’exportation ou de l’impression du contexte. > \[!WARNING] > Lors de la création de flux de travail et d’actions, vous devez toujours déterminer si votre code pourrait exécuter des entrées non fiables provenant de personnes malveillantes potentielles. Certains contextes doivent être traités comme des entrées non fiables, car un attaquant peut insérer son propre contenu malveillant. 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#good-practices-for-mitigating-script-injection-attacks) ». | Nom de la propriété | Type | Description | | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `github` | `object` | Contexte de niveau supérieur disponible pendant tout travail ou étape d’un workflow. Cet objet contient toutes les propriétés répertoriées ci-dessous. | | `github.action` | `string` | Nom de l’action en cours d’exécution ou [`id`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsid) d’une étape. | | GitHub supprime les caractères spéciaux et utilise le nom `__run` lorsque l’étape actuelle exécute un script sans `id`. Si vous utilisez la même action plusieurs fois dans le même travail, le nom inclut un suffixe avec le numéro de séquence avec un trait de soulignement avant celui-ci. Par exemple, le premier script que vous exécutez aura le nom `__run` et le deuxième script sera nommé `__run_2`. De même, le deuxième appel de `actions/checkout` sera `actionscheckout2`. | | | | `github.action_path` | `string` | Chemin où figure une action. Cette propriété est prise en charge uniquement dans les actions composites. Vous pouvez utiliser ce chemin d’accès pour accéder aux fichiers situés dans le même référentiel que l’action, par exemple en modifiant les répertoires en chemin d’accès (à l’aide de la variable d’environnement correspondante) : `cd "$GITHUB_ACTION_PATH"`. Pour plus d’informations sur les variables d’environnement, consultez [Informations de référence sur l’utilisation sécurisée](/fr/enterprise-server@3.22/actions/reference/security/secure-use#use-an-intermediate-environment-variable). | | `github.action_ref` | `string` | Pour une étape exécutant une action, il s’agit de la référence de l’action en cours d’exécution. Par exemple : `v2`.

N’utilisez pas le mot clé `run`. Pour que ce contexte fonctionne avec des actions composites, référencez-le dans le contexte `env` de l’action composite. | | `github.action_repository` | `string` | Pour une étape exécutant une action, il s’agit du propriétaire et du nom du dépôt de l’action. Par exemple : `actions/checkout`.

N’utilisez pas le mot clé `run`. Pour que ce contexte fonctionne avec des actions composites, référencez-le dans le contexte `env` de l’action composite. | | `github.action_status` | `string` | Pour une action composite, il s’agit du résultat actuel de l’action composite. | | `github.actor` | `string` | Le nom d’utilisateur de l’utilisateur ayant déclenché l’exécution initiale du workflow. Si l’exécution du workflow est une réexécution, cette valeur peut être différente de `github.triggering_actor`. Toutes les réexécutions de workflow utilisent les privilèges de `github.actor`, même si l’acteur qui initie la réexécution (`github.triggering_actor`) a des privilèges différents. | | `github.actor_id` | `string` | ID de compte de la personne ou de l’application qui a déclenché l’exécution initiale du workflow. Par exemple : `1234567`. Notez qu’il diffère du nom d’utilisateur de l’acteur. | | `github.api_url` | `string` | URL de l’API GitHub REST. | | | | | | `github.artifacts` | `string` | Chemin d’accès de l’exécuteur au fichier qui identifie les artefacts de flux de travail pour l’étape actuelle. Écrivez une déclaration par ligne pour identifier les fichiers ou les références de synthèse OCI en tant qu’artefacts de flux de travail. Pour plus d’informations, consultez « [Commandes de flux de travail pour GitHub Actions](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#declaring-workflow-artifacts) ». | | `github.artifacts_list` | `string` | Chemin d’accès de l’exécuteur à un fichier en lecture seule contenant les métadonnées d’artefact de flux de travail agrégées pour le travail actuel en tant que JSON. Pour plus d’informations, consultez « [Commandes de flux de travail pour GitHub Actions](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#reading-workflow-artifacts) ». | | | | | | `github.base_ref` | `string` | Branche cible ou `base_ref` de la demande de tirage (pull request) dans une exécution de workflow. Cette propriété est disponible uniquement quand l’événement qui déclenche une exécution de workflow est `pull_request` ou `pull_request_target`. | | `github.env` | `string` | Chemin sur l’exécuteur jusqu’au fichier qui définit les variables d’environnement à partir des commandes de workflow. Ce fichier est unique à l’étape actuelle et est différent pour chaque étape d’un travail. Pour plus d’informations, consultez « [Commandes de flux de travail pour GitHub Actions](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#setting-an-environment-variable) ». | | `github.event` | `object` | Charge utile complète du webhook d’événement. Vous pouvez accéder aux propriétés individuelles de l’événement à l’aide de ce contexte. Cet objet est identique à la charge utile de webhook de l’événement qui a déclenché l’exécution du workflow et il est différent pour chaque événement. Les webhooks pour chaque GitHub Actions événement sont liés dans [É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). Par exemple, pour une exécution de workflow déclenchée par l’événement [`push`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#push), cet objet contient le contenu de la [charge utile du webhook push](/fr/enterprise-server@3.22/webhooks/webhook-events-and-payloads#push). | | `github.event_name` | `string` | Nom de l’événement qui a déclenché l’exécution de workflow. | | `github.event_path` | `string` | Chemin jusqu’au fichier sur l’exécuteur qui contient la charge utile de webhook d’événement complet. | | `github.graphql_url` | `string` | URL de l’API GitHub GraphQL. | | `github.head_ref` | `string` | Branche source ou `head_ref` de la demande de tirage dans une exécution de workflow. Cette propriété est disponible uniquement quand l’événement qui déclenche une exécution de workflow est `pull_request` ou `pull_request_target`. | | `github.job` | `string` | | | \[ | | | | `job_id` | | | | ]\(/actions/reference/workflows-and-actions/workflow-syntax#jobsjob\_id) du travail en cours.
Remarque : Cette propriété de contexte est définie par l’exécuteur Actions et est uniquement disponible au sein des `steps` d’exécution d’un travail. Sinon, la valeur de cette propriété est `null`. | | | | `github.path` | `string` | Chemin sur l’exécuteur vers le fichier qui définit les variables `PATH` système à partir des commandes de workflow. Ce fichier est unique à l’étape actuelle et est différent pour chaque étape d’un travail. Pour plus d’informations, consultez « [Commandes de flux de travail pour GitHub Actions](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-commands#adding-a-system-path) ». | | `github.ref` | `string` | Référence complète de la branche ou de l’étiquette qui a déclenché l’exécution du workflow. Pour les workflows déclenchés par `push`, il s'agit de la branche ou de la référence de tag qui a été poussée. Pour les flux de travail déclenchés par `pull_request` et qui n’ont pas été fusionnés, il s’agit de la branche de fusion du pull request. Si le pull request a été fusionné, c'est la branche dans laquelle il a été fusionné. Pour les workflows déclenchés par `release`, c'est la balise de version créée. Pour les autres déclencheurs, il s’agit de la branche ou de la référence de tag qui a déclenché l’exécution du flux de travail. Cette variable est définie uniquement si une branche ou une étiquette est disponible pour le type d’événement. La référence donnée est entièrement formée, ce qui signifie que pour les branches, le format est `refs/heads/`. Pour les événements de pull request, à l’exception de ceux qui n’ont pas été fusionnés, il s’agit `refs/pull//merge`. Les événements `pull_request_target` possèdent le `ref` de la branche de base. Pour les balises, le format est `refs/tags/`. Par exemple : `refs/heads/feature-branch-1`. Pour plus d’informations sur les branches de pull requests, consultez [Requêtes de tirage](/fr/enterprise-server@3.22/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#pull-request-refs-and-merge-branches). | | `github.ref_name` | `string` | Nom de référence court de la branche ou de l’étiquette qui a déclenché l’exécution du workflow. Cette valeur correspond au nom de la branche ou de l’étiquette indiquée sur GitHub. Par exemple : `feature-branch-1`.

Pour les requêtes de tirage qui n’ont pas été fusionnées, le format est `/merge`. | | `github.ref_protected` | `boolean` | `true` si les protections de branche sont configurés pour la référence qui a déclenché l’exécution du flux de travail. | | `github.ref_type` | `string` | Type de référence qui a déclenché l’exécution du workflow. Les valeurs valides sont `branch` ou `tag`. | | `github.repository` | `string` | Nom du propriétaire et du dépôt. Par exemple : `octocat/Hello-World`. | | `github.repository_id` | `string` | ID du dépôt. Par exemple : `123456789`. Notez qu’il diffère du nom du dépôt. | | `github.repository_owner` | `string` | Nom d’utilisateur du propriétaire du dépôt. Par exemple : `octocat`. | | `github.repository_owner_id` | `string` | ID de compte du propriétaire du dépôt. Par exemple : `1234567`. Notez qu’il diffère du nom du propriétaire. | | `github.repositoryUrl` | `string` | URL Git vers le dépôt. Par exemple : `git://github.com/octocat/hello-world.git`. | | `github.retention_days` | `string` | Nombre de jours pendant lesquels les journaux et artefacts d’exécution de workflow sont conservés. | | `github.run_id` | `string` | Numéro unique pour chaque exécution de workflow dans un dépôt. Ce numéro ne change pas si vous réexécutez l’exécution de workflow. | | `github.run_number` | `string` | Numéro unique de chaque exécution d’un workflow particulier dans un dépôt. Ce nombre commence à 1 pour la première exécution du workflow et s’incrémente à chaque nouvelle exécution. Ce numéro ne change pas si vous réexécutez l’exécution de workflow. | | `github.run_attempt` | `string` | Numéro unique pour chaque tentative d’exécution d’un workflow particulier dans un dépôt. Ce numéro commence à 1 pour la première tentative d’exécution du workflow et augmente d’une unité à chaque nouvelle exécution. | | `github.secret_source` | `string` | Source d’un secret utilisé dans un workflow. Les valeurs possibles sont `None`, , `Actions`ou .`Dependabot` | | `github.server_url` | `string` | URL du serveur GitHub. Par exemple : `https://github.com`. | | `github.sha` | `string` | SHA de commit qui a déclenché le workflow. La valeur de ce SHA de commit dépend de l’événement qui a déclenché le workflow. 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) ». Par exemple : `ffac537e6cbbf934b08745a378932722df287a53`. | | `github.token` | `string` | Jeton permettant de s’authentifier pour le compte de l’application GitHub installée sur votre dépôt. Ceci est fonctionnellement équivalent au secret `GITHUB_TOKEN`. 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) ».
Remarque : Cette propriété de contexte est définie par l’exécuteur Actions et est uniquement disponible au sein des `steps` d’exécution d’un travail. Sinon, la valeur de cette propriété est `null`. | | `github.triggering_actor` | `string` | Nom d’utilisateur de l’utilisateur ayant lancé l’exécution du workflow. Si l’exécution du workflow est une réexécution, cette valeur peut être différente de `github.actor`. Toutes les réexécutions de workflow utilisent les privilèges de `github.actor`, même si l’acteur qui initie la réexécution (`github.triggering_actor`) a des privilèges différents. | | `github.workflow` | `string` | Nom du workflow. Si le fichier de workflow ne spécifie pas un `name`, la valeur de cette propriété est le chemin complet du fichier de workflow dans le dépôt. | | `github.workflow_ref` | `string` | Chemin de référence du workflow. Par exemple : `octocat/hello-world/.github/workflows/my-workflow.yml@refs/heads/my_branch`. | | `github.workflow_sha` | `string` | SHA de commit pour le fichier de workflow. | | `github.workspace` | `string` | Répertoire de travail par défaut sur l’exécuteur pour les étapes et emplacement par défaut de votre dépôt lors de l’utilisation de l’action [`checkout`](https://github.com/actions/checkout). | ### Exemple de contenu du contexte `github` L’exemple de contexte suivant provient d’une exécution de workflow déclenchée par l’événement `push`. L’objet `event` de cet exemple a été tronqué, car il est identique au contenu de la charge utile du webhook [`push`](/fr/enterprise-server@3.22/webhooks/webhook-events-and-payloads#push). > \[!NOTE] > Ce contexte est uniquement un exemple. Le contenu d’un contexte dépend du workflow que vous exécutez. Les contextes, les objets et les propriétés varient considérablement dans les différentes conditions d’exécution des workflows. ```json { "token": "***", "job": "dump_contexts_to_log", "ref": "refs/heads/my_branch", "sha": "c27d339ee6075c1f744c5d4b200f7901aad2c369", "repository": "octocat/hello-world", "repository_owner": "octocat", "repositoryUrl": "git://github.com/octocat/hello-world.git", "run_id": "1536140711", "run_number": "314", "retention_days": "90", "run_attempt": "1", "actor": "octocat", "workflow": "Context testing", "head_ref": "", "base_ref": "", "event_name": "push", "event": { ... }, "server_url": "https://github.com", "api_url": "https://api.github.com", "graphql_url": "https://api.github.com/graphql", "ref_name": "my_branch", "ref_protected": false, "ref_type": "branch", "secret_source": "Actions", "workspace": "/home/runner/work/hello-world/hello-world", "action": "github_step", "event_path": "/home/runner/work/_temp/_github_workflow/event.json", "action_repository": "", "action_ref": "", "path": "/home/runner/work/_temp/_runner_file_commands/add_path_b037e7b5-1c88-48e2-bf78-eaaab5e02602", "env": "/home/runner/work/_temp/_runner_file_commands/set_env_b037e7b5-1c88-48e2-bf78-eaaab5e02602" } ``` ### Exemple d’utilisation du contexte `github` Cet exemple de workflow utilise le contexte `github.event_name` pour exécuter un travail uniquement si l’exécution du workflow a été déclenchée par l’événement `pull_request`. ```yaml copy name: Run CI on: [push, pull_request] jobs: normal_ci: runs-on: ubuntu-latest steps: - name: Run normal CI run: echo "Running normal CI" pull_request_ci: runs-on: ubuntu-latest if: ${{ github.event_name == 'pull_request' }} steps: - name: Run PR CI run: echo "Running PR only CI" ``` ## Contexte `env` Le contexte `env` contient des variables qui ont été définies dans un workflow, un travail ou une étape. Il ne contient pas de variables héritées par le processus de l’exécuteur. Pour plus d’informations sur la définition des variables dans votre workflow, consultez [Syntaxe de flux de travail pour GitHub Actions](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#env). Vous pouvez récupérer les valeurs des variables stockées dans le contexte `env` et les utiliser dans votre fichier de workflow. Vous pouvez utiliser le contexte `env` dans n’importe quelle clé d’une étape du workflow, à l’exception des clés `id` et `uses`. Pour plus d’informations sur la syntaxe des étapes, consultez [Syntaxe de flux de travail pour GitHub Actions](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idsteps). Si vous souhaitez utiliser la valeur d’une variable à l’intérieur d’un exécuteur, utilisez la méthode habituelle du système d’exploitation de l’exécuteur pour lire les variables d’environnement. | Nom de la propriété | Type | Description | | ------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `env` | `object` | Ce contexte change pour chaque étape d’un travail. Vous pouvez accéder à ce contexte à partir de n’importe quelle étape d’un travail. Cet objet contient les propriétés listées ci-dessous. | | `env.` | `string` | Valeur d’une variable d’environnement spécifique. | ### Exemple de contenu du contexte `env` Le contenu du contexte `env` est un mappage des noms de variables à leurs valeurs. Le contenu du contexte peut changer en fonction de l’emplacement où il est utilisé dans l’exécution du workflow. Dans cet exemple, le contexte `env` contient deux variables. ```json { "first_name": "Mona", "super_duper_var": "totally_awesome" } ``` ### Exemple d’utilisation du contexte `env` Cet exemple de workflow montre des variables définies dans le contexte `env` au niveau du workflow, du travail et des étapes. La syntaxe `${{ env.VARIABLE-NAME }}` est ensuite utilisée pour récupérer les valeurs des variables dans les différentes étapes du workflow. 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. ```yaml copy name: Hi Mascot on: push env: mascot: Mona super_duper_var: totally_awesome jobs: windows_job: runs-on: windows-latest steps: - run: echo 'Hi ${{ env.mascot }}' # Hi Mona - run: echo 'Hi ${{ env.mascot }}' # Hi Octocat env: mascot: Octocat linux_job: runs-on: ubuntu-latest env: mascot: Tux steps: - run: echo 'Hi ${{ env.mascot }}' # Hi Tux ``` ## Contexte `vars` Le contexte `vars` contient des variables de configuration personnalisées définies au niveau de l’organisation, du dépôt et de l’environnement. Pour plus d’informations sur la définition de variables de configuration à utiliser dans plusieurs workflows, consultez [Stocker des informations dans des variables](/fr/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables#defining-configuration-variables-for-multiple-workflows). ### Exemple de contenu du contexte `vars` Le contenu du contexte `vars` est un mappage des noms de variables de configuration à leurs valeurs. ```json { "mascot": "Mona" } ``` ### Exemple d’utilisation du contexte `vars` Cet exemple de workflow montre comment les variables de configuration définies au niveau du dépôt, de l’environnement ou de l’organisation sont automatiquement disponibles à l’aide du contexte `vars`. > \[!NOTE] > Les variables de configuration au niveau de l’environnement sont automatiquement disponibles une fois que leur environnement est déclaré par l’exécuteur. Si aucune variable de configuration n’a été définie, la valeur retournée d’un contexte référençant la variable est une chaîne vide. L’exemple suivant montre l’utilisation de variables de configuration avec le contexte `vars` dans un workflow. Chacune des variables de configuration suivantes a été définie au niveau du dépôt, de l’organisation ou de l’environnement. ```yaml copy on: workflow_dispatch: env: # Setting an environment variable with the value of a configuration variable env_var: ${{ vars.ENV_CONTEXT_VAR }} jobs: display-variables: name: ${{ vars.JOB_NAME }} # You can use configuration variables with the `vars` context for dynamic jobs if: ${{ vars.USE_VARIABLES == 'true' }} runs-on: ${{ vars.RUNNER }} environment: ${{ vars.ENVIRONMENT_STAGE }} steps: - name: Use variables run: | echo "repository variable : $REPOSITORY_VAR" echo "organization variable : $ORGANIZATION_VAR" echo "overridden variable : $OVERRIDE_VAR" echo "variable from shell environment : $env_var" env: REPOSITORY_VAR: ${{ vars.REPOSITORY_VAR }} ORGANIZATION_VAR: ${{ vars.ORGANIZATION_VAR }} OVERRIDE_VAR: ${{ vars.OVERRIDE_VAR }} - name: ${{ vars.HELLO_WORLD_STEP }} if: ${{ vars.HELLO_WORLD_ENABLED == 'true' }} uses: actions/hello-world-javascript-action@main with: who-to-greet: ${{ vars.GREET_NAME }} ``` ## Contexte `job` Le contexte `job` contient des informations sur le travail en cours d’exécution. | Nom de la propriété | Type | Description | | ----------------------------------- | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `job` | `object` | Ce contexte change pour chaque travail d’une exécution de workflow. Vous pouvez accéder à ce contexte à partir de n’importe quelle étape d’un travail. Cet objet contient toutes les propriétés répertoriées ci-dessous. | | | | | | `job.container` | `object` | Informations sur le conteneur du travail. Pour plus d’informations sur les conteneurs, consultez [Syntaxe de flux de travail pour GitHub Actions](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idcontainer). | | `job.container.id` | `string` | ID du conteneur. | | `job.container.network` | `string` | ID du réseau de conteneurs. L’exécuteur crée le réseau utilisé par tous les conteneurs dans un travail. | | `job.services` | `object` | Conteneurs de service créés pour un travail. Pour plus d’informations sur les conteneurs de service, consultez [Syntaxe de flux de travail pour GitHub Actions](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idservices). | | `job.services..id` | `string` | ID du conteneur de service. | | `job.services..network` | `string` | ID du réseau de conteneurs de service. L’exécuteur crée le réseau utilisé par tous les conteneurs dans un travail. | | `job.services..ports` | `object` | Ports exposés du conteneur de service. | | `job.status` | `string` | L’état actuel du travail. Les valeurs possibles sont `success`, `failure` ou `cancelled`. | | `job.workflow_ref` | `string` | Référence complète du fichier de flux de travail qui définit le travail actuel. Par exemple : `octo-org/octo-repo/.github/workflows/deploy.yml@refs/heads/main`. Pour les travaux définis directement dans un fichier de flux de travail, il s’agit de la même chose que `github.workflow_ref`. Pour les travaux définis dans un [Réutiliser des workflows](/fr/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows), cela fait référence au fichier de flux de travail réutilisable. (non disponible sur GitHub Enterprise Server) | | `job.workflow_sha` | `string` | Le hachage SHA du commit du fichier de workflow qui définit la tâche actuelle. (non disponible sur GitHub Enterprise Server) | | `job.workflow_repository` | `string` | Le dépôt `owner/repo` contenant le fichier de flux de travail qui définit le travail actuel. Par exemple : `octo-org/octo-repo`. (non disponible sur GitHub Enterprise Server) | | `job.workflow_file_path` | `string` | Chemin d’accès du fichier de flux de travail qui définit le travail actuel, par rapport à la racine du référentiel. Par exemple : `.github/workflows/deploy.yml`. (non disponible sur GitHub Enterprise Server) | ### Exemple de contenu du contexte `job` Cet exemple de contexte `job` utilise un conteneur de service PostgreSQL avec des ports mappés. S’il n’existe aucun conteneur ou conteneur de service utilisé dans un travail, le `job` contexte ne contient que `status`. Les propriétés d’identité de flux de travail (`check_run_id`, `workflow_ref`, `workflow_sha`, `workflow_repository`, `workflow_file_path`) ne sont pas disponibles sur GitHub Enterprise Server. ```json { "status": "success", "check_run_id": 51725241954, "workflow_ref": "octo-org/octo-repo/.github/workflows/deploy.yml@refs/heads/main", "workflow_sha": "abc123def456789abc123def456789abc123def4", "workflow_repository": "octo-org/octo-repo", "workflow_file_path": ".github/workflows/deploy.yml", "container": { "network": "github_network_53269bd575974817b43f4733536b200c" }, "services": { "postgres": { "id": "60972d9aa486605e66b0dad4abb638dc3d9116f566579e418166eedb8abb9105", "ports": { "5432": "49153" }, "network": "github_network_53269bd575974817b43f4733536b200c" } } } ``` ### Exemple d’utilisation du contexte `job` Cet exemple de workflow configure un conteneur de service PostgreSQL et mappe automatiquement le port 5432 dans le conteneur de service à un port disponible choisi de manière aléatoire sur l’hôte. Le contexte `job` est utilisé pour accéder au numéro du port affecté sur l’hôte. ```yaml copy name: PostgreSQL Service Example on: push jobs: postgres-job: runs-on: ubuntu-latest services: postgres: image: postgres env: POSTGRES_PASSWORD: postgres options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5 ports: # Maps TCP port 5432 in the service container to a randomly chosen available port on the host. - 5432 steps: - run: pg_isready -h localhost -p ${{ job.services.postgres.ports[5432] }} - run: echo "Run tests against Postgres" ``` ### Exemple d’utilisation de l’identité de contexte de flux de travail `job` > \[!NOTE] > Les `job.workflow_*` propriétés de contexte ne sont pas disponibles sur GitHub Enterprise Server. Cet exemple de flux de travail réutilisable utilise `job.workflow_repository` et `job.workflow_sha` pour extraire son propre code source, plutôt que le référentiel de l’appelant. Cela est utile lorsqu’un flux de travail réutilisable doit accéder aux fichiers colocalisés avec la définition de flux de travail. ```yaml copy # In a reusable workflow (e.g., octo-org/shared-workflows/.github/workflows/deploy.yml) name: Reusable deploy workflow on: workflow_call: jobs: deploy: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 with: repository: ${{ job.workflow_repository }} ref: ${{ job.workflow_sha }} - run: echo "Deploying from ${{ job.workflow_ref }}" - run: echo "Workflow file path is ${{ job.workflow_file_path }}" ``` ## Contexte `jobs` Le contexte `jobs` est disponible uniquement dans les workflows réutilisables et peut uniquement être utilisé dans le but de définir des sorties pour un workflow réutilisable. Pour plus d’informations, consultez « [Réutiliser des workflows](/fr/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows#using-outputs-from-a-reusable-workflow) ». | Nom de la propriété | Type | Description | | ------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `jobs` | `object` | Ceci est disponible uniquement dans les workflows réutilisables et peut uniquement être utilisé dans le but de définir des sorties pour un workflow réutilisable. Cet objet contient toutes les propriétés répertoriées ci-dessous. | | `jobs..result` | `string` | Résultat d’un travail dans le workflow réutilisable. Les valeurs possibles sont `success`, `failure`, `cancelled` ou `skipped`. | | `jobs..outputs` | `object` | Ensemble de sorties d’un travail dans un workflow réutilisable. | | `jobs..outputs.` | `string` | Valeur d’une sortie spécifique pour un travail dans un workflow réutilisable. | ### Exemple de contenu du contexte `jobs` Cet exemple de contexte `jobs` contient le résultat et les sorties d’un travail provenant de l’exécution d’un workflow réutilisable. ```json { "example_job": { "result": "success", "outputs": { "output1": "hello", "output2": "world" } } } ``` ### Exemple d’utilisation du contexte `jobs` Cet exemple de workflow réutilisable utilise le contexte `jobs` afin de définir des sorties pour le workflow réutilisable. Notez comment les sorties passent des étapes au travail, puis au déclencheur `workflow_call`. Pour plus d’informations, consultez « [Réutiliser des workflows](/fr/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows#using-outputs-from-a-reusable-workflow) ». ```yaml copy name: Reusable workflow on: workflow_call: # Map the workflow outputs to job outputs outputs: firstword: description: "The first output string" value: ${{ jobs.example_job.outputs.output1 }} secondword: description: "The second output string" value: ${{ jobs.example_job.outputs.output2 }} jobs: example_job: name: Generate output runs-on: ubuntu-latest # Map the job outputs to step outputs outputs: output1: ${{ steps.step1.outputs.firstword }} output2: ${{ steps.step2.outputs.secondword }} steps: - id: step1 run: echo "firstword=hello" >> $GITHUB_OUTPUT - id: step2 run: echo "secondword=world" >> $GITHUB_OUTPUT ``` ## Contexte `steps` Le contexte `steps` contient des informations sur les étapes du travail en cours qui ont un [`id`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsid) spécifié et qui ont déjà été exécutées. | Nom de la propriété | Type | Description | | --------------------------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `steps` | `object` | Ce contexte change pour chaque étape d’un travail. Vous pouvez accéder à ce contexte à partir de n’importe quelle étape d’un travail. Cet objet contient toutes les propriétés répertoriées ci-dessous. | | `steps..outputs` | `object` | Ensemble de sorties définies pour l’étape. Pour plus d’informations, consultez « [Référence syntaxique des métadonnées](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/metadata-syntax#outputs-for-docker-container-and-javascript-actions) ». | | `steps..conclusion` | `string` | Résultat d’une étape terminée après l’application de [`continue-on-error`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepscontinue-on-error). Les valeurs possibles sont `success`, `failure`, `cancelled` ou `skipped`. Quand une étape `continue-on-error` échoue, `outcome` a pour valeur `failure`, mais la `conclusion` finale a pour valeur `success`. | | `steps..outcome` | `string` | Résultat d’une étape terminée avant l’application de [`continue-on-error`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepscontinue-on-error). Les valeurs possibles sont `success`, `failure`, `cancelled` ou `skipped`. Quand une étape `continue-on-error` échoue, `outcome` a pour valeur `failure`, mais la `conclusion` finale a pour valeur `success`. | | `steps..outputs.` | `string` | Valeur d’une sortie spécifique. | ### Exemple de contenu du contexte `steps` Cet exemple de contexte `steps` montre deux étapes précédentes qui avaient un [`id`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idstepsid) spécifié. La première étape avait un `id` nommé `checkout`, et la seconde `generate_number`. L’étape `generate_number` avait une sortie nommée `random_number`. ```json { "checkout": { "outputs": {}, "outcome": "success", "conclusion": "success" }, "generate_number": { "outputs": { "random_number": "1" }, "outcome": "success", "conclusion": "success" } } ``` ### Exemple d’utilisation du contexte `steps` Cet exemple de workflow génère un nombre aléatoire en tant que sortie en une étape, et une étape ultérieure utilise le contexte `steps` pour lire la valeur de cette sortie. ```yaml copy name: Generate random failure on: push jobs: randomly-failing-job: runs-on: ubuntu-latest steps: - name: Generate 0 or 1 id: generate_number run: echo "random_number=$(($RANDOM % 2))" >> $GITHUB_OUTPUT - name: Pass or fail run: | if [[ ${{ steps.generate_number.outputs.random_number }} == 0 ]]; then exit 0; else exit 1; fi ``` ## Contexte `runner` Le contexte `runner` contient des informations sur l’exécuteur qui exécute le travail en cours. | Nom de la propriété | Type | Description | | -------------------- | -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `runner` | `object` | Ce contexte change pour chaque travail d’une exécution de workflow. Cet objet contient toutes les propriétés répertoriées ci-dessous. | | `runner.name` | `string` | Nom de l’exécuteur du travail. Ce nom peut ne pas être unique dans l’exécution d’un flux de travail, car les exécutants au niveau du référentiel et de l'organisation peuvent utiliser le même nom. | | `runner.os` | `string` | Système d’exploitation de l’exécuteur du travail. Les valeurs possibles sont `Linux`, `Windows` ou `macOS`. | | `runner.arch` | `string` | Architecture de l’exécuteur qui exécute le travail. Les valeurs possibles sont `X86`, `X64`, `ARM` ou `ARM64`. | | `runner.temp` | `string` | Chemin d’un répertoire temporaire sur l’exécuteur. Ce répertoire est vidé au début et à la fin de chaque travail. Notez que les fichiers ne sont pas supprimés si le compte d’utilisateur de l’exécuteur n’a pas l’autorisation de les supprimer. | | `runner.tool_cache` | `string` | Chemin vers le répertoire contenant les outils préinstallés pour les exécuteurs hébergés par GitHub. Pour plus d’informations, consultez « [Exécuteurs hébergés par GitHub](/fr/enterprise-server@3.22/actions/concepts/runners/github-hosted-runners#preinstalled-software-for-github-owned-images) ». | | `runner.debug` | `string` | Cela est défini seulement si la [journalisation du débogage](/fr/enterprise-server@3.22/actions/how-tos/monitor-workflows/enable-debug-logging) est activée et a toujours la valeur `1`. À titre indicatif, il peut être utile d’activer un débogage supplémentaire ou une journalisation détaillée dans vos propres étapes de travail. | | `runner.environment` | `string` | L’environnement de l’exécuteur de la tâche. Les valeurs possibles sont les suivantes : `github-hosted` pour les exécuteurs hébergés par GitHub fournis par GitHub et `self-hosted` pour les exécuteurs auto-hébergés configurés par le propriétaire du référentiel. | ### Exemple de contenu du contexte `runner` L’exemple de contexte suivant provient d’un exécuteur Linux GitHub hébergé. ```json { "os": "Linux", "arch": "X64", "name": "GitHub Actions 2", "tool_cache": "/opt/hostedtoolcache", "temp": "/home/runner/work/_temp" } ``` ### Exemple d’utilisation du contexte `runner` Cet exemple de workflow utilise le contexte `runner` pour définir le chemin jusqu’au répertoire temporaire afin d’écrire les journaux et, si le workflow échoue, il charge ces journaux en tant qu’artefact. ```yaml copy name: Build on: push jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v6 - name: Build with logs run: | mkdir ${{ runner.temp }}/build_logs echo "Logs from building" > ${{ runner.temp }}/build_logs/build.logs exit 1 - name: Upload logs on fail if: ${{ failure() }} uses: actions/upload-artifact@v3 with: name: Build failure logs path: ${{ runner.temp }}/build_logs ``` ## Contexte `secrets` Le contexte `secrets` contient les noms et les valeurs des secrets disponibles pour une exécution de workflow. Le contexte `secrets` n’est pas disponible pour les actions composites pour des raisons de sécurité. Si vous souhaitez passer un secret à une action composite, vous devez le faire explicitement en tant qu’entrée. Pour plus d’informations sur les secrets, consultez [Utilisation de secrets dans GitHub Actions](/fr/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets). `GITHUB_TOKEN` est un secret qui est créé automatiquement pour chaque exécution de workflow et qui est toujours inclus dans le contexte `secrets`. 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) ». > \[!WARNING] > Si un secret est utilisé dans une tâche de flux de travail, GitHub masque automatiquement les secrets imprimés dans le journal. Vous devez éviter d’imprimer intentionnellement des secrets dans le journal d’activité. | Nom de la propriété | Type | Description | | ----------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `secrets` | `object` | Ce contexte est le même pour chaque travail dans une exécution de workflow. Vous pouvez accéder à ce contexte à partir de n’importe quelle étape d’un travail. Cet objet contient toutes les propriétés répertoriées ci-dessous. | | `secrets.GITHUB_TOKEN` | `string` | Jeton créé automatiquement pour chaque exécution de workflow. 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) ». | | `secrets.` | `string` | Valeur d’un secret spécifique. | ### Exemple de contenu du contexte `secrets` L’exemple de contenu suivant du contexte `secrets` montre le jeton `GITHUB_TOKEN` automatique, ainsi que deux autres secrets disponibles pour l’exécution du workflow. ```json { "github_token": "***", "NPM_TOKEN": "***", "SUPERSECRET": "***" } ``` ### Exemple d’utilisation du contexte `secrets` Cet exemple de flux de travail utilise le[CLI GitHub](/fr/enterprise-server@3.22/actions/how-tos/write-workflows/choose-what-workflows-do/use-github-cli), qui nécessite `GITHUB_TOKEN` en tant que valeur du paramètre d’entrée de `GH_TOKEN` : ```yaml copy name: Open new issue on: workflow_dispatch jobs: open-issue: runs-on: ubuntu-latest permissions: contents: read issues: write steps: - run: | gh issue --repo ${{ github.repository }} \ create --title "Issue title" --body "Issue body" env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} ``` ## Contexte `strategy` Pour les workflows avec une matrice, le contexte `strategy` contient des informations sur la stratégie d’exécution de matrice pour le travail en cours. | Nom de la propriété | Type | Description | | ---------------------------------------------------------------------------------------------------------------------------------------------------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `strategy` | `object` | Ce contexte change pour chaque travail d’une exécution de workflow. Vous pouvez accéder à ce contexte à partir de n’importe quel travail ou étape d’un workflow. Cet objet contient toutes les propriétés répertoriées ci-dessous. | | `strategy.fail-fast` | `boolean` | Lorsque cette valeur est `true`, tous les travaux en cours sont annulés si un travail d’une matrice échoue. 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#jobsjob_idstrategyfail-fast) ». | | `strategy.job-index` | `number` | Index du travail en cours dans la matrice. | | **Remarque :** ce nombre est un nombre basé sur zéro. L’index du premier travail dans la matrice est `0`. | | | | `strategy.job-total` | `number` | Nombre total de travaux dans la matrice. | | **Remarque :** ce nombre **n’est pas** un nombre basé sur zéro. Par exemple, pour une matrice avec quatre travaux, la valeur de `job-total` est `4`. | | | | `strategy.max-parallel` | `number` | Nombre maximal de travaux pouvant s’exécuter simultanément lors de l’utilisation d’une stratégie de travail `matrix`. 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#jobsjob_idstrategymax-parallel) ». | ### Exemple de contenu du contexte `strategy` L’exemple de contenu suivant du contexte `strategy` provient d’une matrice avec quatre travaux et est extrait du travail final. Notez la différence entre le nombre `job-index` basé sur zéro et `job-total` qui n’est pas basé sur zéro. ```json { "fail-fast": true, "job-index": 3, "job-total": 4, "max-parallel": 4 } ``` ### Exemple d’utilisation du contexte `strategy` Cet exemple de workflow utilise la propriété `strategy.job-index` pour définir un nom unique pour un fichier journal pour chaque travail d’une matrice. ```yaml copy name: Test strategy on: push jobs: test: runs-on: ubuntu-latest strategy: matrix: test-group: [1, 2] node: [14, 16] steps: - run: echo "Mock test logs" > test-job-${{ strategy.job-index }}.txt - name: Upload logs uses: actions/upload-artifact@v3 with: name: Build log for job ${{ strategy.job-index }} path: test-job-${{ strategy.job-index }}.txt ``` ## Contexte `matrix` Pour les workflows avec une matrice, le contexte `matrix` contient les propriétés de matrice définies dans le fichier de workflow qui s’appliquent au travail en cours. Par exemple, si vous configurez une matrice avec les clés `os` et `node`, l’objet de contexte `matrix` inclut les propriétés `os` et `node` avec les valeurs en cours d’utilisation pour le travail en cours. Aucune propriété standard ne figure dans le contexte `matrix`, uniquement celles qui sont définies dans le fichier de workflow. | Nom de la propriété | Type | Description | | ------------------------ | -------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `matrix` | `object` | Ce contexte est disponible uniquement pour les travaux d’une matrice, et il change pour chaque travail d’une exécution de workflow. Vous pouvez accéder à ce contexte à partir de n’importe quel travail ou étape d’un workflow. Cet objet contient les propriétés listées ci-dessous. | | `matrix.` | `string` | Valeur d’une propriété de matrice. | ### Exemple de contenu du contexte `matrix` L’exemple de contenu suivant du contexte `matrix` provient d’un travail dans une matrice dont les propriétés de matrice `os` et `node` sont définies dans le workflow. Le travail exécute la combinaison matricielle d’un système d’exploitation `ubuntu-latest` et de la version `16` de Node.js. ```json { "os": "ubuntu-latest", "node": 16 } ``` ### Exemple d’utilisation du contexte `matrix` Cet exemple de workflow crée une matrice avec les clés `os` et `node`. Il utilise la propriété `matrix.os` pour définir le type d’exécuteur pour chaque travail et utilise la propriété `matrix.node` pour définir la version de Node.js pour chaque travail. ```yaml copy name: Test matrix on: push jobs: build: runs-on: ${{ matrix.os }} strategy: matrix: os: [ubuntu-latest, windows-latest] node: [14, 16] steps: - uses: actions/setup-node@v7 with: node-version: ${{ matrix.node }} - name: Output node version run: node --version ``` ## Contexte `needs` Le contexte `needs` contient des sorties provenant de tous les travaux définis comme une dépendance directe du travail en cours. Notez que cela n’inclut pas les travaux dépendants implicitement (par exemple, les travaux dépendants d’un travail dépendant). Pour plus d’informations sur la définition de dépendances de travail, consultez [Syntaxe de flux de travail pour GitHub Actions](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idneeds). | Nom de la propriété | Type | Description | | -------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `needs` | `object` | Ce contexte est rempli uniquement pour les exécutions de workflow qui ont des travaux dépendants, et il change pour chaque travail d’une exécution de workflow. Vous pouvez accéder à ce contexte à partir de n’importe quel travail ou étape d’un workflow. Cet objet contient toutes les propriétés répertoriées ci-dessous. | | `needs.` | `object` | Travail unique dont dépend le travail en cours. | | `needs..outputs` | `object` | Ensemble de sorties d’un travail dont dépend le travail en cours. | | `needs..outputs.` | `string` | Valeur d’une sortie spécifique pour un travail dont dépend le travail en cours. | | `needs..result` | `string` | Résultat d’un travail dont dépend le travail en cours. Les valeurs possibles sont `success`, `failure`, `cancelled` ou `skipped`. | ### Exemple de contenu du contexte `needs` L’exemple de contenu suivant du contexte `needs` montre des informations pour deux travaux dont dépend le travail en cours. ```json { "build": { "result": "success", "outputs": { "build_id": "123456" } }, "deploy": { "result": "failure", "outputs": {} } } ``` ### Exemple d’utilisation du contexte `needs` Cet exemple de workflow comporte trois travaux : un travail `build` qui crée une build, un travail `deploy` qui nécessite le travail `build` et un travail `debug` qui nécessite les travaux `build` et `deploy`, et qui s’exécute uniquement en cas d’échec dans le workflow. Le travail `deploy` utilise également le contexte `needs` pour accéder à une sortie du travail `build`. ```yaml copy name: Build and deploy on: push jobs: build: runs-on: ubuntu-latest outputs: build_id: ${{ steps.build_step.outputs.build_id }} steps: - name: Build id: build_step run: echo "build_id=$RANDOM" >> $GITHUB_OUTPUT deploy: needs: build runs-on: ubuntu-latest steps: - run: echo "Deploying build ${{ needs.build.outputs.build_id }}" debug: needs: [build, deploy] runs-on: ubuntu-latest if: ${{ failure() }} steps: - run: echo "Failed to build and deploy" ``` ## Contexte `inputs` Le contexte `inputs` contient les propriétés d’entrée transmises à une action, à un workflow réutilisable ou à un workflow déclenché manuellement. Pour les workflows réutilisables, les noms et types d’entrée sont définis dans la configuration de l’événement [`workflow_call`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows) d’un workflow réutilisable. Les valeurs d’entrée sont transmises depuis [`jobs..with`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idwith) dans un workflow externe qui appelle le workflow réutilisable. Pour les workflows déclenchés manuellement, les entrées sont définies dans la configuration de l’événement [`workflow_dispatch`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_dispatch) d’un workflow. Les propriétés du contexte `inputs` sont définies dans le fichier de workflow. Elles sont disponibles uniquement dans un [workflow réutilisable](/fr/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows) ou dans un workflow déclenché par l’événement [`workflow_dispatch`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_dispatch). | Nom de la propriété | Type | Description | | --------------------------------------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `inputs` | `object` | Ce contexte est disponible uniquement dans un [workflow réutilisable](/fr/enterprise-server@3.22/actions/how-tos/reuse-automations/reuse-workflows) ou dans un workflow déclenché par l’événement [`workflow_dispatch`](/fr/enterprise-server@3.22/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_dispatch). Vous pouvez accéder à ce contexte à partir de n’importe quel travail ou étape d’un workflow. Cet objet contient les propriétés listées ci-dessous. | | `inputs.` | | | | `string` ou `number` ou `boolean` ou `choice` | Chaque valeur d’entrée transmise à partir d’un workflow externe. | | ### Exemple de contenu du contexte `inputs` L’exemple de contenu suivant du contexte `inputs` provient d’un workflow qui a défini les entrées `build_id`, `deploy_target` et `perform_deploy`. ```json { "build_id": 123456768, "deploy_target": "deployment_sys_1a", "perform_deploy": true } ``` ### Exemple d’utilisation du contexte `inputs` dans un workflow réutilisable Cet exemple de workflow réutilisable tire parti du contexte `inputs` pour obtenir les valeurs des entrées `build_id`, `deploy_target` et `perform_deploy` qui ont été passées au workflow réutilisable à partir du workflow appelant. ```yaml copy name: Reusable deploy workflow on: workflow_call: inputs: build_id: required: true type: number deploy_target: required: true type: string perform_deploy: required: true type: boolean jobs: deploy: runs-on: ubuntu-latest if: ${{ inputs.perform_deploy }} steps: - name: Deploy build to target run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}" ``` ### Exemple d’utilisation du contexte `inputs` dans un workflow déclenché manuellement Cet exemple de workflow déclenché par un événement `workflow_dispatch` utilise le contexte `inputs` pour obtenir les valeurs des entrées `build_id`, `deploy_target` et `perform_deploy` qui ont été passées au workflow. ```yaml copy on: workflow_dispatch: inputs: build_id: required: true type: string deploy_target: required: true type: string perform_deploy: required: true type: boolean jobs: deploy: runs-on: ubuntu-latest if: ${{ inputs.perform_deploy }} steps: - name: Deploy build to target run: echo "Deploying build:${{ inputs.build_id }} to target:${{ inputs.deploy_target }}" ``` ## Pour aller plus loin * [Contextes](/fr/enterprise-server@3.22/actions/concepts/workflows-and-actions/contexts)