About workflows

About workflows

Un workflow est un processus automatisé configurable qui exécutera un ou plusieurs travaux. Les workflows sont définis par un fichier YAML archivé dans votre dépôt et s’exécutent lorsqu’ils sont déclenchés par un événement dans votre dépôt, ou ils peuvent être déclenchés manuellement ou selon une planification définie.

Les workflows sont définis dans l’annuaire .github/workflows d’un dépôt. Un référentiel peut comporter plusieurs workflows, chacun d’entre eux pouvant effectuer un ensemble de tâches différentes, telles que :

• Construire et tester les demandes de tirage
• Déployer votre application à chaque fois qu'une version est créée
• Ajout d'une étiquette à chaque fois qu'un nouveau numéro est ouvert

Workflow basics

A workflow must contain the following basic components:

1. One or more events that will trigger the workflow.
2. One or more jobs, each of which will execute on a runner machine and run a series of one or more steps.
3. Each step can either run a script that you define or run an action, which is a reusable extension that can simplify your workflow.

For more information on these basic components, see Comprendre GitHub Actions.

Triggering a workflow

Les déclencheurs de workflow sont des événements qui entraînent l’exécution d’un workflow. Ces événements peuvent être les suivants :

• Événements qui se produisent dans le dépôt de votre workflow
• Événements qui se produisent en dehors de GitHub et qui déclenchent un événement repository_dispatch sur GitHub
• Heures planifiées
• Manuel

Par exemple, vous pouvez configurer votre workflow pour qu’il s’exécute lorsqu’un push est effectué vers la branche par défaut de votre dépôt, lorsqu’une version est créée ou lorsqu’un problème est ouvert.

For more information, see Déclenchement d’un workflow, and for a full list of events, see Events that trigger workflows.

Workflow syntax

Workflows are defined using YAML. For the full reference of the YAML syntax for authoring workflows, see Workflow syntax for GitHub Actions.

For more on managing workflow runs, such as re-running, cancelling, or deleting a workflow run, see Gestion des exécutions et des déploiements de workflow.

Using workflow templates

GitHub fournit des modèles de flux de travail préconfigurés que vous pouvez utiliser tels quels ou personnaliser pour créer votre propre flux de travail. GitHub analyse votre code et vous affiche des modèles de flux de travail qui pourraient être utiles pour votre référentiel. Par exemple, si votre référentiel contient du code Node.js, vous verrez des suggestions de projets Node.js.

Ces modèles de workflow sont conçus pour vous aider à être rapidement opérationnel, en offrant une gamme de configurations telles que :

• CI : workflows d’intégration continue
• Déploiements : workflows de déploiement
• Automatisation : automatisation des workflows
• Analyse du code : workflows d’analyse du code
• Pages : workflows de pages

Utilisez ces workflows comme point de départ pour générer votre propre workflow ou utilisez-les tels quels. Vous pouvez parcourir la liste complète des modèles de flux de travail dans le référentiel actions/starter-workflows.

Advanced workflow features

This section briefly describes some of the advanced features of GitHub Actions that help you create more complex workflows.

Storing secrets

If your workflows use sensitive data, such as passwords or certificates, you can save these in GitHub as secrets and then use them in your workflows as environment variables. This means that you will be able to create and share workflows without having to embed sensitive values directly in the workflow's YAML source.

This example job demonstrates how to reference an existing secret as an environment variable, and send it as a parameter to an example command.

jobs:
  example-job:
    runs-on: ubuntu-latest
    steps:
      - name: Retrieve secret
        env:
          super_secret: ${{ secrets.SUPERSECRET }}
        run: |
          example-command "$super_secret"

For more information, see Utilisation de secrets dans GitHub Actions.

Creating dependent jobs

By default, the jobs in your workflow all run in parallel at the same time. If you have a job that must only run after another job has completed, you can use the needs keyword to create this dependency. If one of the jobs fails, all dependent jobs are skipped; however, if you need the jobs to continue, you can define this using the if conditional statement.

In this example, the setup, build, and test jobs run in series, with build and test being dependent on the successful completion of the job that precedes them:

jobs:
  setup:
    runs-on: ubuntu-latest
    steps:
      - run: ./setup_server.sh
  build:
    needs: setup
    runs-on: ubuntu-latest
    steps:
      - run: ./build_server.sh
  test:
    needs: build
    runs-on: ubuntu-latest
    steps:
      - run: ./test_server.sh

For more information, see Utilisation de travaux dans un workflow.

Using a matrix

Une stratégie de matrice vous permet d’utiliser des variables dans une définition de travail unique pour créer automatiquement plusieurs exécutions de travaux basées sur les combinaisons des variables. Par exemple, vous pouvez utiliser une stratégie de matrice pour tester votre code dans plusieurs versions d’un langage ou sur plusieurs systèmes d’exploitation. The matrix is created using the strategy keyword, which receives the build options as an array. For example, this matrix will run the job multiple times, using different versions of Node.js:

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node: [14, 16]
    steps:
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node }}

For more information, see Exécution de variantes de tâches dans un workflow.

Caching dependencies

If your jobs regularly reuse dependencies, you can consider caching these files to help improve performance. Once the cache is created, it is available to all workflows in the same repository.

This example demonstrates how to cache the ~/.npm directory:

jobs:
  example-job:
    steps:
      - name: Cache node modules
        uses: actions/cache@v4
        env:
          cache-name: cache-node-modules
        with:
          path: ~/.npm
          key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-build-${{ env.cache-name }}-

For more information, see Mise en cache des dépendances pour accélérer les workflows.

Using databases and service containers

If your job requires a database or cache service, you can use the services keyword to create an ephemeral container to host the service; the resulting container is then available to all steps in that job and is removed when the job has completed. This example demonstrates how a job can use services to create a postgres container, and then use node to connect to the service.

jobs:
  container-job:
    runs-on: ubuntu-latest
    container: node:20-bookworm-slim
    services:
      postgres:
        image: postgres
    steps:
      - name: Check out repository code
        uses: actions/checkout@v4
      - name: Install dependencies
        run: npm ci
      - name: Connect to PostgreSQL
        run: node client.js
        env:
          POSTGRES_HOST: postgres
          POSTGRES_PORT: 5432

For more information, see Utilisation des services conteneurisés.

Using labels to route workflows

If you want to be sure that a particular type of runner will process your job, you can use labels to control where jobs are executed. You can assign labels to a self-hosted runner in addition to their default label of self-hosted. Then, you can refer to these labels in your YAML workflow, ensuring that the job is routed in a predictable way. GitHub-hosted runners have predefined labels assigned.

This example shows how a workflow can use labels to specify the required runner:

jobs:
  example-job:
    runs-on: [self-hosted, linux, x64, gpu]

A workflow will only run on a runner that has all the labels in the runs-on array. The job will preferentially go to an idle self-hosted runner with the specified labels.

To learn more about self-hosted runner labels, see Utilisation d’étiquettes avec des exécuteurs auto-hébergés.

Reusing workflows

Vous pouvez partager des flux de travail avec votre organisation, publiquement ou en privé, en appelant un workflow à partir d’un autre. Cela vous permet de réutiliser des workflows, d’éviter leur duplication et de faciliter leur maintenance. Pour plus d’informations, consultez « Réutilisation des workflows ».

Security hardening for workflows

GitHub fournit des fonctionnalités de sécurité que vous pouvez utiliser pour augmenter la sécurité de vos flux de travail. Vous pouvez utiliser les fonctionnalités intégrées GitHub pour vous assurer que vous êtes informé des vulnérabilités dans les actions que vous consommez ou pour automatiser le processus d’actualisation des actions dans vos flux de travail. Pour plus d’informations, consultez « Utiliser les fonctions de sécurité de GitHub pour sécuriser votre utilisation des actions GitHub ».

Using environments

You can configure environments with protection rules and secrets to control the execution of jobs in a workflow. Each job in a workflow can reference a single environment. Any protection rules configured for the environment must pass before a job referencing the environment is sent to a runner. For more information, see Gestion des environnements pour le déploiement.