Skip to main content

Contextes

Vous pouvez accéder aux informations de contexte dans les workflows et les actions.

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 « Présentation du risque d’injections de scripts ».

Nom du contexteTypeDescription
githubobjectInformations sur l’exécution du workflow. Pour plus d’informations, consultez Contexte github.
envobjectContient des variables définies dans un workflow, un travail ou une étape. Pour plus d’informations, consultez Contexte env.

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 d’environnement par défaut ».
  • 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 ».

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"

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 | | ---- | ------- | ----------------- | | concurrency | github, inputs | | | env | github, secrets, inputs | | | jobs.<job_id>.concurrency | github, needs, strategy, matrix, inputs | | | jobs.<job_id>.container | github, needs, strategy, matrix, env, secrets, inputs | | | jobs.<job_id>.container.credentials | github, needs, strategy, matrix, env, secrets, inputs | | | jobs.<job_id>.container.env.<env_id> | github, needs, strategy, matrix, job, runner, env, secrets, inputs | | | jobs.<job_id>.continue-on-error | github, needs, strategy, matrix, inputs | | | jobs.<job_id>.defaults.run | github, needs, strategy, matrix, env, inputs | | | jobs.<job_id>.env | github, needs, strategy, matrix, secrets, inputs | | | jobs.<job_id>.environment | github, needs, strategy, matrix, inputs | | | jobs.<job_id>.environment.url | github, needs, strategy, matrix, job, runner, env, steps, inputs | | | jobs.<job_id>.if | github, needs, inputs | always, cancelled, success, failure | | jobs.<job_id>.name | github, needs, strategy, matrix, inputs | | | jobs.<job_id>.outputs.<output_id> | github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs | | | jobs.<job_id>.runs-on | github, needs, strategy, matrix, inputs | | | jobs.<job_id>.secrets.<secrets_id> | github, needs, secrets | | | jobs.<job_id>.services | github, needs, strategy, matrix, inputs | | | jobs.<job_id>.services.<service_id>.credentials | github, needs, strategy, matrix, env, secrets, inputs | | | jobs.<job_id>.services.<service_id>.env.<env_id> | github, needs, strategy, matrix, job, runner, env, secrets, inputs | | | jobs.<job_id>.steps.continue-on-error | github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs | hashFiles | | jobs.<job_id>.steps.env | github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs | hashFiles | | jobs.<job_id>.steps.if | github, needs, strategy, matrix, job, runner, env, steps, inputs | always, cancelled, success, failure, hashFiles | | jobs.<job_id>.steps.name | github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs | hashFiles | | jobs.<job_id>.steps.run | github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs | hashFiles | | jobs.<job_id>.steps.timeout-minutes | github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs | hashFiles | | jobs.<job_id>.steps.with | github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs | hashFiles | | jobs.<job_id>.steps.working-directory | github, needs, strategy, matrix, job, runner, env, secrets, steps, inputs | hashFiles | | jobs.<job_id>.strategy | github, needs, inputs | | | jobs.<job_id>.timeout-minutes | github, needs, strategy, matrix, inputs | | | jobs.<job_id>.with.<with_id> | github, needs | | | on.workflow_call.inputs.<inputs_id>.default | github | | | on.workflow_call.outputs.<output_id>.value | github, jobs, inputs | |

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.

YAML
name: Context testing
on: push

jobs:
  dump_contexts_to_log:
    runs-on: ubuntu-latest
    steps:
      - name: Dump GitHub context
        id: github_context_step
        run: echo '${{ toJSON(github) }}'
      - name: Dump job context
        run: echo '${{ toJSON(job) }}'
      - name: Dump steps context
        run: echo '${{ toJSON(steps) }}'
      - name: Dump runner context
        run: echo '${{ toJSON(runner) }}'
      - name: Dump strategy context
        run: echo '${{ toJSON(strategy) }}'
      - name: Dump matrix context
        run: echo '${{ toJSON(matrix) }}'

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 « Utilisation des variables d’environnement ».

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 « Présentation du risque d’injections de scripts ».

Nom de la propriétéTypeDescription
githubobjectContexte 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.actionstringNom 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_pathstringChemin 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_refstringPour 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.
github.action_repositorystringPour 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.
github.action_statusstringPour une action composite, il s’agit du résultat actuel de l’action composite.
github.actorstringNom d’utilisateur de l’utilisateur qui a initié l’exécution du workflow.

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.

YAML
name: Run CI
on: [push, pull_request]

jobs:
  normal_ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Run normal CI
        run: ./run-tests

  pull_request_ci:
    runs-on: ubuntu-latest
    if: ${{ github.event_name == 'pull_request' }}
    steps:
      - uses: actions/checkout@v3
      - name: Run PR CI
        run: ./run-additional-pr-ci

Contexte env

Le contexte env contient des variables qui ont été définies dans un workflow, un travail ou une étape. Pour plus d’informations sur la définition des variables dans votre workflow, consultez « Syntaxe de workflow pour GitHub Actions ».

La syntaxe du contexte env vous permet d’utiliser la valeur d’une variable dans votre fichier de workflow. Vous pouvez utiliser le contexte env dans la valeur de n’importe quelle clé dans une étape, à l’exception des clés id et uses. Pour plus d’informations sur la syntaxe de l’étape, consultez « Syntaxe de workflow pour 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éTypeDescription
envobjectCe 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>stringValeur 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.

{
  "first_name": "Mona",
  "super_duper_var": "totally_awesome"
}

Exemple d’utilisation du contexte env

Cet exemple de workflow montre comment le contexte env peut être configuré au niveau du workflow, du travail et des étapes, ainsi que l’utilisation du contexte dans les étapes.

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
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 job

Le contexte job contient des informations sur le travail en cours d’exécution.

Nom de la propriétéTypeDescription
jobobjectCe 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.containerobjectInformations sur le conteneur du travail. Pour plus d’informations sur les conteneurs, consultez « Syntaxe de workflow pour GitHub Actions ».
job.container.idstringID du conteneur.
job.container.networkstringID du réseau de conteneurs. L’exécuteur crée le réseau utilisé par tous les conteneurs dans un travail.
job.servicesobjectConteneurs de service créés pour un travail. Pour plus d’informations sur les conteneurs de service, consultez « Syntaxe de workflow pour GitHub Actions ».
job.services.<service_id>.idstringID du conteneur de service.
job.services.<service_id>.networkstringID 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>.portsobjectPorts exposés du conteneur de service.
job.statusstringL’é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.

YAML
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:
      - uses: actions/checkout@v3
      - run: pg_isready -h localhost -p ${{ job.services.postgres.ports[5432] }}
      - run: ./run-tests

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 de workflows ».

Nom de la propriétéTypeDescription
jobsobjectCeci 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>.resultstringRésultat d’un travail dans le workflow réutilisable. Les valeurs possibles sont success, failure, cancelled ou skipped.
jobs.<job_id>.outputsobjectEnsemble de sorties d’un travail dans un workflow réutilisable.
jobs.<job_id>.outputs.<output_name>stringValeur 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 de workflows ».

YAML
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 "::set-output name=firstword::hello"
      - id: step2
        run: echo "::set-output name=secondword::world"

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éTypeDescription
stepsobjectCe 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>.outputsobjectEnsemble de sorties définies pour l’étape. Pour plus d’informations, consultez « Syntaxe des métadonnées pour GitHub Actions ».
steps.<step_id>.conclusionstringRé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>.outcomestringRé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>stringValeur 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.

YAML
name: Generate random failure
on: push
jobs:
  randomly-failing-job:
    runs-on: ubuntu-latest
    steps:
      - id: checkout
        uses: actions/checkout@v3
      - name: Generate 0 or 1
        id: generate_number
        run:  echo "::set-output name=random_number::$(($RANDOM % 2))"
      - 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éTypeDescription
runnerobjectCe 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.namestringNom de l’exécuteur du travail.
runner.osstringSystème d’exploitation de l’exécuteur du travail. Les valeurs possibles sont Linux, Windows ou macOS.
runner.archstringArchitecture de l’exécuteur qui exécute le travail. Les valeurs possibles sont X86, X64, ARM ou ARM64.
runner.tempstringChemin 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_cachestringChemin du répertoire contenant des outils préinstallés pour les exécuteurs hébergés par GitHub. Pour plus d’informations, consultez « À propos des exécuteurs hébergés par GitHub ».
runner.debugstringCela 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.

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.

YAML
name: Build
on: push

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Build with logs
        run: |
          mkdir ${{ runner.temp }}/build_logs
          ./build.sh --log-path ${{ runner.temp }}/build_logs
      - 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 « Secrets chiffrés ».

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 automatique par jeton ».

Avertissement : GitHub expurge automatiquement les secrets imprimés dans le journal, mais vous devez éviter d’imprimer intentionnellement des secrets dans le journal.

Nom de la propriétéTypeDescription
secretsobjectCe 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_TOKENstringJeton créé automatiquement pour chaque exécution de workflow. Pour plus d’informations, consultez « Authentification automatique par jeton ».
secrets.<secret_name>stringValeur 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 workflow utilise l’action d’étiqueteur, qui nécessite GITHUB_TOKEN en tant que valeur du paramètre d’entrée repo-token :

YAML
name: Pull request labeler
on: [ pull_request_target ]

permissions:
  contents: read
  pull-requests: write

jobs:
  triage:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/labeler@v4
        with:
          repo-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éTypeDescription
strategyobjectCe 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-fastbooleanQuand true, tous les travaux en cours sont annulés si un travail d’une matrice échoue. Pour plus d’informations, consultez « Syntaxe de workflow pour GitHub Actions ».
strategy.job-indexnumberIndex 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-totalnumberNombre 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-parallelnumberNombre 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 workflow pour 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.

YAML
name: Test matrix
on: push

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        test-group: [1, 2]
        node: [14, 16]
    steps:
      - uses: actions/checkout@v3
      - run: npm test > 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éTypeDescription
matrixobjectCe 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>stringValeur 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.

YAML
name: Test matrix
on: push

jobs:
  build:
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest]
        node: [14, 16]
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: ${{ matrix.node }}
      - name: Install dependencies
        run: npm ci
      - name: Run tests
        run: npm test

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 des dépendances de travail, consultez « Syntaxe de workflow pour GitHub Actions ».

Nom de la propriétéTypeDescription
needsobjectCe 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>objectTravail unique dont dépend le travail en cours.
needs.<job_id>.outputsobjectEnsemble de sorties d’un travail dont dépend le travail en cours.
needs.<job_id>.outputs.<output name>stringValeur d’une sortie spécifique pour un travail dont dépend le travail en cours.
needs.<job_id>.resultstringRé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": "ABC123"
    }
  },
  "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
name: Build and deploy
on: push

jobs:
  build:
    runs-on: ubuntu-latest
    outputs:
      build_id: ${{ steps.build_step.outputs.build_id }}
    steps:
      - uses: actions/checkout@v3
      - name: Build
        id: build_step
        run: |
          ./build
          echo "::set-output name=build_id::$BUILD_ID"
  deploy:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: ./deploy --build ${{ needs.build.outputs.build_id }}
  debug:
    needs: [build, deploy]
    runs-on: ubuntu-latest
    if: ${{ failure() }}
    steps:
      - uses: actions/checkout@v3
      - run: ./debug

Contexte inputs

Le contexte inputs contient les propriétés d’entrée passées à une action ou à un workflow réutilisable. Les noms et types d’entrée sont définis dans la configuration d’événement workflow_call d’un workflow réutilisable. Les valeurs d’entrée sont passées à partir de jobs.<job_id>.with dans un workflow externe qui appelle le workflow réutilisable.

Aucune propriété standard ne figure dans le contexte inputs, uniquement celles qui sont définies dans le fichier de workflow.

Nom de la propriétéTypeDescription
inputsobjectCe contexte est disponible uniquement dans un workflow réutilisable. 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 booleanChaque 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.

YAML
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: deploy --build ${{ inputs.build_id }} --target ${{ inputs.deploy_target }}