Skip to main content
Nous publions des mises à jour fréquentes de notre documentation, et la traduction de cette page peut encore être en cours. Pour obtenir les informations les plus actuelles, consultez la documentation anglaise.

Cette version de GitHub Enterprise a été abandonnée le 2023-03-15. Aucune publication de correctifs n’est effectuée, même pour les problèmes de sécurité critiques. Pour de meilleures performances, une sécurité améliorée et de nouvelles fonctionnalités, effectuez une mise à niveau vers la dernière version de GitHub Enterprise. Pour obtenir de l’aide sur la mise à niveau, contactez le support GitHub Enterprise.

Workflow commands for GitHub Actions

Vous pouvez utiliser des commandes de workflow quand vous exécutez des commandes d’interpréteur de commandes dans un workflow ou dans le code d’une action.

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 commandes de workflow

Les actions peuvent communiquer avec la machine de l’exécuteur pour définir des variables d’environnement, générer des valeurs utilisées par d’autres actions, ajouter des messages de débogage aux journaux de sortie, entre autres tâches.

La plupart des commandes de workflow utilisent la commande echo dans un format spécifique, tandis que d’autres sont appelées en écrivant dans un fichier. Pour plus d’informations, consultez « Fichiers d’environnement ».

Exemple de commande de workflow

Shell
echo "::workflow-command parameter1={data},parameter2={data}::{command value}"
pwsh
Write-Output "::workflow-command parameter1={data},parameter2={data}::{command value}"

Remarque : Les noms de commandes et de paramètres de workflow ne respectent pas la casse.

Avertissement : Si vous utilisez l’invite de commandes, omettez les guillemets doubles (") lors de l’utilisation de commandes de workflow.

Utilisation de commandes de workflow pour accéder aux fonctions du kit de ressources

Les actions/le kit de ressources incluent un certain nombre de fonctions qui peuvent être exécutées en tant que commandes de workflow. Utilisez la syntaxe :: pour exécuter les commandes de workflow dans votre fichier YAML. Ces commandes sont ensuite envoyées à l’exécuteur via stdout. Par exemple, au lieu d’utiliser du code pour définir une sortie, comme ci-dessous :

JavaScript
core.setOutput('SELECTED_COLOR', 'green');

Exemple : Définition d’une valeur

Vous pouvez utiliser la commande set-output dans votre workflow pour définir la même valeur :

YAML
      - name: Set selected color
        run: echo '::set-output name=SELECTED_COLOR::green'
        id: random-color-generator
      - name: Get color
        run: echo "The selected color is ${{ steps.random-color-generator.outputs.SELECTED_COLOR }}"
YAML
      - name: Set selected color
        run: Write-Output "::set-output name=SELECTED_COLOR::green"
        id: random-color-generator
      - name: Get color
        run: Write-Output "The selected color is ${{ steps.random-color-generator.outputs.SELECTED_COLOR }}"

Le tableau suivant montre quelles fonctions du kit de ressources sont disponibles dans un workflow :

Fonction du kit de ressourcesCommande de workflow équivalente
core.addPathAccessible à l’aide du fichier d’environnement GITHUB_PATH
core.debugdebug
core.noticenotice
core.errorerror
core.endGroupendgroup
core.exportVariableAccessible à l’aide du fichier d’environnement GITHUB_ENV
core.getInputAccessible à l’aide de la variable d’environnement INPUT_{NAME}
core.getStateAccessible à l’aide de la variable d’environnement STATE_{NAME}
core.isDebugAccessible à l’aide de la variable d’environnement RUNNER_DEBUG

Définition d’un paramètre de sortie

Définit le paramètre de sortie d’une action.

Code
::set-output name={name}::{value}

Si vous le souhaitez, vous pouvez également déclarer des paramètres de sortie dans le fichier de métadonnées d’une action. Pour plus d’informations, consultez « Metadata syntax for GitHub Actions ».

Vous pouvez échapper des chaînes multilignes pour définir un paramètre de sortie en créant une variable d’environnement et en l’utilisant dans une commande de workflow. Pour plus d’informations, consultez « Définition d’une variable d’environnement ».

Exemple : Définition d’un paramètre de sortie

Shell
echo "::set-output name=action_fruit::strawberry"
pwsh
Write-Output "::set-output name=action_fruit::strawberry"

Définition d’un message de débogage

Imprime un message de débogage dans le journal. Vous devez créer un secret nommé ACTIONS_STEP_DEBUG avec la valeur true pour afficher les messages de débogage définis par cette commande dans le journal. Pour plus d’informations, consultez « Enabling debug logging ».

Code
::debug::{message}

Exemple : Définition d’un message de débogage

Shell
echo "::debug::Set the Octocat variable"
pwsh
Write-Output "::debug::Set the Octocat variable"

Définition d’un message de notification

Crée un message de notification et l’imprime dans le journal. Ce message crée une annotation, qui peut associer le message à un fichier particulier de votre dépôt. Votre message peut éventuellement spécifier une position dans le fichier.

Code
::notice file={name},line={line},endLine={endLine},title={title}::{message}
ParamètreValeur
titleTitre personnalisé
fileNom de fichier
colNuméro de colonne, à partir de 1
endColumnNuméro de colonne de fin
lineNuméro de ligne, à partir de 1
endLineNuméro de ligne de fin

Exemple : Définition d’un message de notification

Shell
echo "::notice file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
pwsh
Write-Output "::notice file=app.js,line=1,col=5,endColumn=7::Missing semicolon"

Définition d’un message d’avertissement

Crée un message d’avertissement et l’imprime dans le journal. Ce message crée une annotation, qui peut associer le message à un fichier particulier de votre dépôt. Votre message peut éventuellement spécifier une position dans le fichier.

Code
::warning file={name},line={line},endLine={endLine},title={title}::{message}
ParamètreValeur
titleTitre personnalisé
fileNom de fichier
colNuméro de colonne, à partir de 1
endColumnNuméro de colonne de fin
lineNuméro de ligne, à partir de 1
endLineNuméro de ligne de fin

Exemple : Définition d’un message d’avertissement

Shell
echo "::warning file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
pwsh
Write-Output "::warning file=app.js,line=1,col=5,endColumn=7::Missing semicolon"

Définition d’un message d’erreur

Crée un message d’erreur et l’imprime dans le journal. Ce message crée une annotation, qui peut associer le message à un fichier particulier de votre dépôt. Votre message peut éventuellement spécifier une position dans le fichier.

Code
::error file={name},line={line},endLine={endLine},title={title}::{message}
ParamètreValeur
titleTitre personnalisé
fileNom de fichier
colNuméro de colonne, à partir de 1
endColumnNuméro de colonne de fin
lineNuméro de ligne, à partir de 1
endLineNuméro de ligne de fin

Exemple : Définition d’un message d’erreur

Shell
echo "::error file=app.js,line=1,col=5,endColumn=7::Missing semicolon"
pwsh
Write-Output "::error file=app.js,line=1,col=5,endColumn=7::Missing semicolon"

Regroupement de lignes de journal

Crée un groupe extensible dans le journal. Pour créer un groupe, utilisez la commande group et spécifiez un titre (title). Tout ce que vous imprimez dans le journal entre les commandes group et endgroup est imbriqué dans une entrée extensible dans le journal.

Code
::group::{title}
::endgroup::

Exemple : Regroupement de lignes de journal

YAML
jobs:
  bash-example:
    runs-on: ubuntu-latest
    steps:
      - name: Group of log lines
        run: |
            echo "::group::My title"
            echo "Inside group"
            echo "::endgroup::"
YAML
jobs:
  powershell-example:
    runs-on: windows-latest
    steps:
      - name: Group of log lines
        run: |
            Write-Output "::group::My title"
            Write-Output "Inside group"
            Write-Output "::endgroup::"

Capture d’écran du journal de l’étape de workflow. La deuxième ligne, « Mon titre », est précédée d’une flèche vers le bas, indiquant un groupe développé. La ligne suivante, « Dans le groupe », est mise en retrait ci-dessous.

Masquage d’une valeur dans le journal

Code
::add-mask::{value}

Le masquage d’une valeur empêche l’impression d’une chaîne ou d’une variable dans le journal. Chaque mot masqué séparé par des espaces blancs est remplacé par le caractère *. Vous pouvez utiliser une variable d’environnement ou une chaîne pour la valeur (value) du masque. Lorsque vous masquez une valeur, elle est traitée comme un secret et est éditée sur l’exécuteur. Par exemple, après avoir masqué une valeur, vous ne pouvez pas définir cette valeur en tant que sortie.

Exemple : Masquage d’une chaîne

Lorsque vous imprimez "Mona The Octocat" dans le journal, vous voyez "***".

Shell
echo "::add-mask::Mona The Octocat"
pwsh
Write-Output "::add-mask::Mona The Octocat"

Avertissement : Veillez à inscrire le secret avec « add-mask » avant de l’afficher dans les journaux de génération ou de l’utiliser dans les autres commandes de workflow.

Exemple : Masquage d’une variable d’environnement

Lorsque vous imprimez la variable MY_NAME ou la valeur "Mona The Octocat" dans le journal, vous voyez "***" au lieu de "Mona The Octocat".

YAML
jobs:
  bash-example:
    runs-on: ubuntu-latest
    env:
      MY_NAME: "Mona The Octocat"
    steps:
      - name: bash-version
        run: echo "::add-mask::$MY_NAME"
YAML
jobs:
  powershell-example:
    runs-on: windows-latest
    env:
      MY_NAME: "Mona The Octocat"
    steps:
      - name: powershell-version
        run: Write-Output "::add-mask::$env:MY_NAME"

Arrêt et démarrage de commandes de workflow

Arrête le traitement de toutes les commandes de workflow. Cette commande spéciale vous permet de tout journaliser sans exécuter accidentellement une commande de workflow. Par exemple, vous pouvez arrêter la journalisation pour générer l’intégralité d’un script contenant des commentaires.

Code
::stop-commands::{endtoken}

Pour arrêter le traitement des commandes de workflow, passez un jeton unique à stop-commands. Pour reprendre le traitement des commandes de workflow, passez le même jeton que celui que vous avez utilisé pour arrêter les commandes de workflow.

Avertissement : Assurez-vous que le jeton que vous utilisez est généré de manière aléatoire et qu’il est unique pour chaque exécution.

Code
::{endtoken}::

Exemple : Arrêt et démarrage de commandes de workflow

YAML
jobs:
  workflow-command-job:
    runs-on: ubuntu-latest
    steps:
      - name: Disable workflow commands
        run: |
          echo '::warning:: This is a warning message, to demonstrate that commands are being processed.'
          stopMarker=$(uuidgen)
          echo "::stop-commands::$stopMarker"
          echo '::warning:: This will NOT be rendered as a warning, because stop-commands has been invoked.'
          echo "::$stopMarker::"
          echo '::warning:: This is a warning again, because stop-commands has been turned off.'
YAML
jobs:
  workflow-command-job:
    runs-on: windows-latest
    steps:
      - name: Disable workflow commands
        run: |
          Write-Output '::warning:: This is a warning message, to demonstrate that commands are being processed.'
          $stopMarker = New-Guid
          Write-Output "::stop-commands::$stopMarker"
          Write-Output '::warning:: This will NOT be rendered as a warning, because stop-commands has been invoked.'
          Write-Output "::$stopMarker::"
          Write-Output '::warning:: This is a warning again, because stop-commands has been turned off.'

Renvoi de sorties de commandes

Active ou désactive le renvoi de commandes de workflow. Par exemple, si vous utilisez la commande set-output dans un workflow, elle définit un paramètre de sortie, mais le journal de l’exécution du workflow n’affiche pas la commande elle-même. Si vous activez le renvoi des commandes, le journal affiche la commande, par exemple ::set-output name={name}::{value}.

Code
::echo::on
::echo::off

Le renvoi des commandes est désactivé par défaut. Toutefois, une commande de workflow est renvoyée en cas d’erreurs lors de son traitement.

Les commandes add-mask, debug, warning et error ne prennent pas en charge le renvoi, car leurs sorties sont déjà répercutées dans le journal.

Vous pouvez également activer le renvoi des commandes globalement en activant la journalisation du débogage par étape à l’aide du secret ACTIONS_STEP_DEBUG. Pour plus d’informations, consultez « Enabling debug logging ». En revanche, la commande de workflow echo vous permet d’activer le renvoi des commandes de façon plus précise, plutôt que de l’activer pour chaque workflow d’un dépôt.

Exemple : Activation/désactivation du renvoi des commandes

YAML
jobs:
  workflow-command-job:
    runs-on: ubuntu-latest
    steps:
      - name: toggle workflow command echoing
        run: |
          echo '::set-output name=action_echo::disabled'
          echo '::echo::on'
          echo '::set-output name=action_echo::enabled'
          echo '::echo::off'
          echo '::set-output name=action_echo::disabled'
YAML
jobs:
  workflow-command-job:
    runs-on: windows-latest
    steps:
      - name: toggle workflow command echoing
        run: |
          write-output "::set-output name=action_echo::disabled"
          write-output "::echo::on"
          write-output "::set-output name=action_echo::enabled"
          write-output "::echo::off"
          write-output "::set-output name=action_echo::disabled"

L’exemple ci-dessus imprime les lignes suivantes dans le journal :

Code
::set-output name=action_echo::enabled
::echo::off

Seules les deuxièmes commandes de workflow set-output et echo sont incluses dans le journal, car le renvoi des commandes n’a été activé que lors de leur exécution. Même s’il n’est pas toujours répercuté, le paramètre de sortie est défini dans tous les cas.

Envoi de valeurs aux actions de préalables (pre) et ultérieures (post)

Vous pouvez utiliser la commande save-state pour créer des variables d’environnement pour les partager avec les actions pre: ou post: de votre workflow. Par exemple, vous pouvez créer un fichier avec l’action pre:, passer l’emplacement du fichier à l’action main:, puis utiliser l’action post: pour supprimer le fichier. Vous pouvez également créer un fichier avec l’action main:, passer l’emplacement du fichier à l’action post:, puis également utiliser l’action post: pour supprimer le fichier.

Si vous avez plusieurs actions pre: ou post:, vous pouvez uniquement accéder à la valeur enregistrée dans l’action où save-state a été utilisé. Pour plus d’informations sur l’action post:, consultez « Metadata syntax for GitHub Actions ».

La commande save-state ne peut être exécutée que dans une action et n’est pas disponible dans les fichiers YAML. La valeur enregistrée est stockée en tant que valeur d’environnement avec le préfixe STATE_.

Cet exemple utilise JavaScript pour exécuter la commande save-state. La variable d’environnement obtenue est nommée STATE_processID avec la valeur 12345 :

JavaScript
console.log('::save-state name=processID::12345')

La variable STATE_processID est ensuite disponible exclusivement pour le script de nettoyage s’exécutant sous l’action main. Cet exemple s’exécute dans main et utilise JavaScript pour afficher la valeur affectée à la variable d’environnement STATE_processID :

JavaScript
console.log("The running PID from the main action is: " +  process.env.STATE_processID);

Fichiers d’environnement

Pendant l’exécution d’un workflow, l’exécuteur génère des fichiers temporaires qui peuvent être utilisés pour effectuer certaines actions. Le chemin de ces fichiers est exposé via des variables d’environnement. Vous devez utiliser l’encodage UTF-8 lors de l’écriture dans ces fichiers pour garantir le traitement approprié des commandes. Plusieurs commandes peuvent être écrites dans le même fichier, séparées par des sauts de ligne.

La plupart des commandes des exemples suivants utilisent des guillemets doubles pour le renvoi des chaînes, qui tenteront d’interpoler des caractères comme $ pour les noms de variables d’interpréteur de commandes. Pour toujours utiliser des valeurs littérales dans des chaînes entre guillemets, vous pouvez utiliser des guillemets simples à la place.

Remarque : Les versions 5.1 et antérieures de PowerShell (shell: powershell) n’utilisent pas UTF-8 par défaut. Vous devez donc spécifier l’encodage UTF-8. Par exemple :

YAML
jobs:
  legacy-powershell-example:
    runs-on: windows-latest
    steps:
      - shell: powershell
        run: |
          "mypath" | Out-File -FilePath $env:GITHUB_PATH -Encoding utf8 -Append

PowerShell Core versions 6 et ultérieures (shell: pwsh) utilisent UTF-8 par défaut. Par exemple :

YAML
jobs:
  powershell-core-example:
    runs-on: windows-latest
    steps:
      - shell: pwsh
        run: |
          "mypath" >> $env:GITHUB_PATH

Définition d’une variable d’environnement

Shell
echo "{environment_variable_name}={value}" >> $GITHUB_ENV
  • Utilisation de PowerShell version 6 et ultérieures :

    pwsh
    "{environment_variable_name}={value}" >> $env:GITHUB_ENV
  • Utilisation de PowerShell version 5.1 et antérieures :

    powershell
    "{environment_variable_name}={value}" | Out-File -FilePath $env:GITHUB_ENV -Encoding utf8 -Append

Vous pouvez rendre une variable d’environnement disponible pour toutes les étapes suivantes d’un travail de workflow en définissant ou en mettant à jour la variable d’environnement, puis en écrivant ceci dans le fichier d’environnement GITHUB_ENV. L’étape qui crée ou met à jour la variable d’environnement n’a pas accès à la nouvelle valeur, mais toutes les étapes suivantes d’un travail y ont accès. Les noms des variables d’environnement respectent la casse et vous pouvez inclure des signes de ponctuation. Pour plus d’informations, consultez « Variables ».

Exemple d’écriture d’une variable d’environnement dans GITHUB_ENV

YAML
steps:
  - name: Set the value
    id: step_one
    run: |
      echo "action_state=yellow" >> $GITHUB_ENV
  - name: Use the value
    id: step_two
    run: |
      echo "${{ env.action_state }}" # This will output 'yellow'
YAML
steps:
  - name: Set the value
    id: step_one
    run: |
      "action_state=yellow" >> $env:GITHUB_ENV
  - name: Use the value
    id: step_two
    run: |
      Write-Output "${{ env.action_state }}" # This will output 'yellow'

Chaînes multilignes

Pour les chaînes multilignes, vous pouvez utiliser un délimiteur avec la syntaxe suivante.

Code
{name}<<{delimiter}
{value}
{delimiter}

Avertissement : Assurez-vous que le séparateur que vous utilisez est généré de manière aléatoire et qu’il est unique pour chaque exécution. Pour plus d’informations, consultez « Durcissement de la sécurité pour GitHub Actions ».

Exemple d’une chaîne multiligne

Cet exemple sélectionne une valeur aléatoire pour $EOF comme délimiteur et définit la variable d’environnement JSON_RESPONSE sur la valeur de la réponse curl.

YAML
steps:
  - name: Set the value in bash
    id: step_one
    run: |
      EOF=$(dd if=/dev/urandom bs=15 count=1 status=none | base64)
      echo "JSON_RESPONSE<<$EOF" >> $GITHUB_ENV
      curl https://example.com >> $GITHUB_ENV
      echo "$EOF" >> $GITHUB_ENV
YAML
steps:
  - name: Set the value in pwsh
    id: step_one
    run: |
      -join (1..15 | ForEach {[char]((48..57)+(65..90)+(97..122) | Get-Random)}) | set EOF
      "JSON_RESPONSE<<$EOF" >> $env:GITHUB_ENV
      (Invoke-WebRequest -Uri "https://example.com").Content >> $env:GITHUB_ENV
      "$EOF" >> $env:GITHUB_ENV
    shell: pwsh

Ajout d’un chemin système

Ajoute un répertoire à la variable système PATH et le rend automatiquement disponible pour toutes les actions suivantes dans le travail actuel. L’action en cours d’exécution ne peut pas accéder à la variable de chemin mise à jour. Pour afficher les chemins actuellement définis pour votre travail, vous pouvez utiliser echo "$PATH" dans une étape ou une action.

Shell
echo "{path}" >> $GITHUB_PATH
pwsh
"{path}" >> $env:GITHUB_PATH

Exemple d’ajout d’un chemin système

Cet exemple montre comment ajouter le répertoire $HOME/.local/bin de l’utilisateur à PATH :

Shell
echo "$HOME/.local/bin" >> $GITHUB_PATH

Cet exemple montre comment ajouter le répertoire $env:HOMEPATH/.local/bin de l’utilisateur à PATH :

pwsh
"$env:HOMEPATH/.local/bin" >> $env:GITHUB_PATH