Remarque : Les exécuteurs hébergés sur GitHub ne sont pas pris en charge sur GitHub Enterprise Server. Vous pouvez voir plus d’informations sur le support futur planifié dans la GitHub public roadmap.
À propos des contextes
Les contextes offrent un moyen d’accéder aux informations sur les exécutions de workflow, les variables, les environnements d’exécuteur, les travaux et les étapes. Chaque contexte est un objet qui contient des propriétés, qui peuvent être des chaînes ou d’autres objets.
Les contextes, les objets et les propriétés varient considérablement dans les différentes conditions d’exécution des workflows. Par exemple, le contexte matrix
est rempli uniquement pour les travaux figurant dans une matrice.
Vous pouvez accéder aux contextes à l’aide de la syntaxe d’expression. Pour plus d’informations, consultez « Expressions ».
${{ <context> }}
Avertissement : Au moment de la création de workflows et d’actions, vous devez toujours déterminer si votre code peut exécuter une entrée non fiable provenant d’attaquants potentiels. 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 « Durcissement de la sécurité pour GitHub Actions ».
Nom du contexte | Type | Description |
---|---|---|
github | object | Informations sur l’exécution du workflow. Pour plus d’informations, consultez Contexte github . |
env | object | Contient des variables définies dans un workflow, un travail ou une étape. Pour plus d’informations, consultez Contexte env . |
vars | object | Contient des variables définies au niveau du référentiel, de l'organisation ou de l'environnement. Pour plus d’informations, consultez Contexte vars . |
job | object | Informations sur le travail en cours d’exécution. Pour plus d’informations, consultez Contexte job . |
jobs | object | Pour les workflows réutilisables uniquement, contient les sorties des travaux du workflow réutilisable. Pour plus d’informations, consultez Contexte jobs . |
steps | object | Informations sur les étapes qui ont été exécutées dans le travail en cours. Pour plus d’informations, consultez Contexte steps . |
runner | object | Informations sur l’exécuteur qui exécute le travail en cours. Pour plus d’informations, consultez Contexte runner . |
secrets | object | Contient les noms et valeurs des secrets disponibles pour une exécution de workflow. Pour plus d’informations, consultez Contexte secrets . |
strategy | object | Informations sur la stratégie d’exécution de matrice pour le travail en cours. Pour plus d’informations, consultez Contexte strategy . |
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, consultez Contexte matrix . |
needs | object | Contient les sorties de tous les travaux définis comme dépendance du travail en cours. Pour plus d’informations, consultez Contexte needs . |
inputs | object | Contient les entrées d’un flux de travail réutilisable ou déclenché manuellement. Pour plus d’informations, consultez Contexte inputs . |
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 par défaut : ces variables d’environnement existent uniquement sur l’exécuteur du travail. Pour plus d’informations, consultez « 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 exemplerunner.os
. Pour plus d’informations sur l’emplacement où vous pouvez utiliser divers contextes au sein d’un workflow, consultez « Disponibilité du contexte ».
L’exemple suivant montre comment ces différents types de variables peuvent être utilisés ensemble dans un travail :
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"
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
pour déterminer le nom de la branche actuelle. Si le nom est refs/heads/main
, les étapes suivantes sont exécutées. La vérification if
est traitée par GitHub Actions, et le travail n’est envoyé à l’exécuteur que 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
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 indique où chaque contexte et chaque fonction spéciale peuvent être utilisés dans un workflow. Si elle n’est pas listée ci-dessous, une fonction peut être utilisée n’importe où.
Clé de workflow | Context | Fonctions spéciales |
---|---|---|
run-name | github, inputs, vars | None |
concurrency | github, inputs, vars | None |
env | github, secrets, inputs, vars | None |
jobs.<job_id>.concurrency | github, needs, strategy, matrix, inputs, vars | None |
jobs.<job_id>.container | github, needs, strategy, matrix, vars, inputs | None |
jobs.<job_id>.container.credentials | github, needs, strategy, matrix, env, vars, secrets, inputs | None |
jobs.<job_id>.container.env.<env_id> | github, needs, strategy, matrix, job, runner, env, vars, secrets, inputs | None |
jobs.<job_id>.container.image | github, needs, strategy, matrix, vars, inputs | None |
jobs.<job_id>.continue-on-error | github, needs, strategy, vars, matrix, inputs | None |
jobs.<job_id>.defaults.run | github, needs, strategy, matrix, env, vars, inputs | None |
jobs.<job_id>.env | github, needs, strategy, matrix, vars, secrets, inputs | None |
jobs.<job_id>.environment | github, needs, strategy, matrix, vars, inputs | None |
jobs.<job_id>.environment.url | github, needs, strategy, matrix, job, runner, env, vars, steps, inputs | None |
jobs.<job_id>.if | github, needs, vars, inputs | always, cancelled, success, failure |
jobs.<job_id>.name | github, needs, strategy, matrix, vars, inputs | None |
jobs.<job_id>.outputs.<output_id> | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | None |
jobs.<job_id>.runs-on | github, needs, strategy, matrix, vars, inputs | None |
jobs.<job_id>.secrets.<secrets_id> | github, needs, strategy, matrix, secrets, inputs, vars | None |
jobs.<job_id>.services | github, needs, strategy, matrix, vars, inputs | None |
jobs.<job_id>.services.<service_id>.credentials | github, needs, strategy, matrix, env, vars, secrets, inputs | None |
jobs.<job_id>.services.<service_id>.env.<env_id> | github, needs, strategy, matrix, job, runner, env, vars, secrets, inputs | None |
jobs.<job_id>.steps.continue-on-error | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | hashFiles |
jobs.<job_id>.steps.env | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | hashFiles |
jobs.<job_id>.steps.if | github, needs, strategy, matrix, job, runner, env, vars, steps, inputs | always, cancelled, success, failure, hashFiles |
jobs.<job_id>.steps.name | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | hashFiles |
jobs.<job_id>.steps.run | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | hashFiles |
jobs.<job_id>.steps.timeout-minutes | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | hashFiles |
jobs.<job_id>.steps.with | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | hashFiles |
jobs.<job_id>.steps.working-directory | github, needs, strategy, matrix, job, runner, env, vars, secrets, steps, inputs | hashFiles |
jobs.<job_id>.strategy | github, needs, vars, inputs | None |
jobs.<job_id>.timeout-minutes | github, needs, strategy, matrix, vars, inputs | None |
jobs.<job_id>.with.<with_id> | github, needs, strategy, matrix, inputs, vars | None |
on.workflow_call.inputs.<inputs_id>.default | github, inputs, vars | None |
on.workflow_call.outputs.<output_id>.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
est nécessaire pour l’impression automatique des objets JSON dans le journal.
Avertissement: 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.
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"
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 également lire la plupart des données du contexte github
dans les variables d’environnement. Pour plus d’informations sur les variables d’environnement, consultez « Variables ».
Avertissement: 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.
Avertissement : Au moment de la création de workflows et d’actions, vous devez toujours déterminer si votre code peut exécuter une entrée non fiable provenant d’attaquants potentiels. 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 « Durcissement de la sécurité pour GitHub Actions ».
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 d’une étape. GitHub supprime les caractères spéciaux et utilise le nom __run quand 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 pour accéder aux fichiers situés dans le même dépôt que l’action, par exemple en remplaçant les répertoires par le chemin : cd ${{ github.action_path }} . |
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 qui a déclenché l’exécution initiale du flux de travail. 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 REST GitHub. |
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 « Workflow commands for GitHub Actions ». |
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 événement GitHub Actions sont liés dans « Événements qui déclenchent des flux de travail ». Par exemple, pour une exécution de workflow déclenchée par l’événement push , cet objet contient le contenu de la charge utile du webhook 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 GraphQL GitHub. |
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 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 d‘accès sur l’exécuteur jusqu’au fichier qui définit les variables du système PATH à partir des commandes de flux de travail. Ce fichier est unique à l’étape actuelle et est différent pour chaque étape d’un travail. Pour plus d’informations, consultez « Workflow commands for GitHub Actions ». |
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 d’étiquette qui a été envoyée. Pour les workflows déclenchés par pull_request , il s’agit de la branche de fusion de la requête de tirage. Pour les workflows déclenchés par release , il s’agit de l’étiquette de mise en production créée. Pour les autres déclencheurs, il s’agit de la branche ou de la référence d’étiquette qui a déclenché l’exécution du workflow. 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 le format est refs/heads/<branch_name> pour les branches, refs/pull/<pr_number>/merge pour les requêtes de tirage et refs/tags/<tag_name> pour les étiquettes. Par exemple : refs/heads/feature-branch-1 . |
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 demandes de tirage, le format est <pr_number>/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 | Le nom d’utilisateur du propriétaire du référentiel. 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 | L’URL Git vers le référentiel. Par exemple : git://github.com/octocat/hello-world.git . |
github.retention_days | string | Le nombre de jours pendant lesquels les journaux et artefacts d’exécution de flux de travail 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 | Un numéro unique pour chaque tentative d’exécution d’un flux de travail particulier dans un référentiel. 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 | La source d’un secret utilisé dans un flux de travail. Les valeurs possibles sont None , Actions ou Dependabot . |
github.server_url | string | L’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 ». Par exemple : ffac537e6cbbf934b08745a378932722df287a53 . |
github.token | string | Un jeton pour s’authentifier au nom de l’application GitHub installée sur votre référentiel. Ceci est fonctionnellement équivalent au secret GITHUB_TOKEN . Pour plus d’informations, consultez « Authentification par jeton automatique ». 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 | Le répertoire de travail par défaut sur l’exécuteur pour les étapes et la localisation par défaut de votre référentiel lors de l’utilisation de l’action 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
.
Remarque : 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.
{
"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
.
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"
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 d’exécuteur. Pour plus d’informations sur la définition des variables dans votre workflow, consultez « Workflow syntax for GitHub Actions ».
Vous pouvez récupérer les valeurs des variables stockées dans le contexte env
et utiliser ces valeurs dans votre fichier de workflow. Vous pouvez utiliser le contexte env
dans n’importe quelle clé à une étape, à l’exception des clés id
et uses
. Pour plus d’informations sur la syntaxe des étapes, consultez « Workflow syntax for GitHub Actions ».
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.<env_name> | 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.
{
"first_name": "Mona",
"super_duper_var": "totally_awesome"
}
Exemple d’utilisation du contexte env
Cet exemple de workflow montre les 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 des valeurs de variables à des étapes individuelles 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.
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
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
Remarque : Les variables de configuration pour GitHub Actions sont en version bêta et sont susceptibles d’être modifiées.
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 « Variables ».
Exemple de contenu du contexte vars
Le contenu du contexte vars
est un mappage des noms de variables de configuration à leurs valeurs.
{
"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
.
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.
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 }}
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 « Workflow syntax for GitHub Actions ». |
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 « Workflow syntax for GitHub Actions ». |
job.services.<service_id>.id | string | ID du conteneur de service. |
job.services.<service_id>.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.<service_id>.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 . |
Exemple de contenu du contexte job
Cet exemple de contexte job
utilise un conteneur de service PostgreSQL avec des ports mappés. En l’absence de conteneurs et de conteneurs de service dans un travail, le contexte job
contient uniquement la propriété status
.
{
"status": "success",
"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.
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"
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"
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éutilisation des workflows ».
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.<job_id>.result | string | Résultat d’un travail dans le workflow réutilisable. Les valeurs possibles sont success , failure , cancelled ou skipped . |
jobs.<job_id>.outputs | object | Ensemble de sorties d’un travail dans un workflow réutilisable. |
jobs.<job_id>.outputs.<output_name> | 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.
{
"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éutilisation des workflows ».
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
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
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.<step_id>.outputs | object | Ensemble de sorties définies pour l’étape. Pour plus d’informations, consultez « Metadata syntax for GitHub Actions ». |
steps.<step_id>.conclusion | string | Résultat d’une étape terminée après l’application de continue-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.<step_id>.outcome | string | Résultat d’une étape terminée avant l’application de continue-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.<step_id>.outputs.<output_name> | 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
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
.
{
"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.
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
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 du répertoire contenant des outils préinstallés pour les exécuteurs hébergés par GitHub. Pour plus d’informations, consultez « Utilisation des exécuteurs hébergés par GitHub ». |
runner.debug | string | Cela est défini seulement si la journalisation du débogage 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 hébergé par GitHub.
{
"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.
name: Build on: push jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - 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
name: Build
on: push
jobs:
build:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- 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 ».
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 « Authentification par jeton automatique ».
Avertissement : Si un secret a été utilisé dans le projet, GitHub retire automatiquement les secrets imprimés dans le journal d’activité. 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 « Authentification par jeton automatique ». |
secrets.<secret_name> | 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.
{
"github_token": "***",
"NPM_TOKEN": "***",
"SUPERSECRET": "***"
}
Exemple d’utilisation du contexte secrets
Cet exemple de flux de travail utilise leCLI GitHub, qui nécessite GITHUB_TOKEN
en tant que valeur du paramètre d’entrée de GH_TOKEN
:
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 }}
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 | Quand cela aboutit à true , tous les travaux en cours sont annulés si un travail d’une matrice échoue. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ». |
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 « Workflow syntax for GitHub Actions ». |
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.
{
"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.
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
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.<property_name> | 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.
{
"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.
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@v4 with: node-version: ${{ matrix.node }} - name: Output node version run: node --version
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@v4
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 « Workflow syntax for GitHub Actions ».
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.<job_id> | object | Travail unique dont dépend le travail en cours. |
needs.<job_id>.outputs | object | Ensemble de sorties d’un travail dont dépend le travail en cours. |
needs.<job_id>.outputs.<output name> | string | Valeur d’une sortie spécifique pour un travail dont dépend le travail en cours. |
needs.<job_id>.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.
{
"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
.
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"
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 context inputs
contient les propriétés d’entrée transmises à une action, à un flux de travail réutilisable ou à un flux de travail déclenché manuellement. Pour les flux de travail réutilisables, les noms et les types d’entrée sont définis dans la configuration des événements workflow_call
d’un flux de travail réutilisable, et les valeurs d’entrée sont transmises dans un flux de travail externe jobs.<job_id>.with
qui appelle le flux de travail réutilisable. Pour les flux de travail déclenchés manuellement, les entrées sont définies dans la configuration d’événement workflow_dispatch
d’un flux de travail.
Les propriétés du contexte inputs
sont définies dans le fichier de workflow. Elles ne sont disponibles que dans un flux de travail réutilisable ou dans un flux de travail déclenché par l’événement workflow_dispatch
Nom de la propriété | Type | Description |
---|---|---|
inputs | object | Ce contexte n’est disponible que dans un flux de travail réutilisable ou dans un flux de travail déclenché par l’événement 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.<name> | 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
.
{
"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.
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 }}"
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.
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 }}"
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 }}"