À propos des workflows

À propos des 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 le répertoire .github/workflows d’un référentiel, et un référentiel peut avoir plusieurs workflows, chacun pouvant effectuer un ensemble différent de tâches. Par exemple, vous pouvez avoir un workflow pour générer et tester des demandes de tirage, un autre workflow pour déployer votre application chaque fois qu’une version est créée, et encore un autre workflow qui ajoute une étiquette chaque fois que quelqu’un ouvre un nouveau problème.

Concepts de workflow de base

Un workflow doit contenir les composants de base suivants :

1. Un ou plusieurs événements qui déclenchent le workflow.
2. Un ou plusieurs travaux, dont chacun s’exécute sur un ordinateur exécuteur et exécute une série d’une ou plusieurs étapes.
3. Chaque étape peut exécuter un script que vous définissez ou une action, qui est une extension réutilisable qui peut simplifier votre workflow.

Pour plus d’informations sur ces composants de base, consultez « Comprendre GitHub Actions ».

Déclenchement d’un 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 Enterprise Server et qui déclenchent un événement repository_dispatch sur GitHub Enterprise Server
• 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.

Pour plus d’informations, consultez « Déclenchement d’un workflow », et pour obtenir la liste complète d’événements, consultez « Événements qui déclenchent des flux de travail ».

Syntaxe des workflows

Les workflows sont définis à l’aide de YAML. Pour obtenir la référence complète de la syntaxe YAML pour la création de workflows, consultez « Workflow syntax for GitHub Actions ».

Créer un exemple de workflow

GitHub Actions utilise la syntaxe YAML pour définir le workflow. Chaque workflow est stocké en tant que fichier YAML distinct dans votre référentiel de code, dans un répertoire appelé .github/workflows.

Vous pouvez créer un exemple de workflow dans votre dépôt qui déclenche automatiquement une série de commandes chaque fois que du code est poussé (push). Dans ce workflow, GitHub Actions extrait le code envoyé, installe le framework de test bats et exécute une commande de base pour générer la version de bats : bats -v.

1. Dans votre dépôt, créez le répertoire .github/workflows/ pour stocker vos fichiers de workflow.

2. Dans le répertoire .github/workflows/, créez un nouveau fichier appelé learn-github-actions.yml et ajoutez le code suivant.

   YAML

   name: learn-github-actions
   run-name: ${{ github.actor }} is learning GitHub Actions
   on: [push]
   jobs:
     check-bats-version:
       runs-on: ubuntu-latest
       steps:
         - uses: actions/checkout@v4
         - uses: actions/setup-node@v4
           with:
             node-version: '14'
         - run: npm install -g bats
         - run: bats -v
   

3. Validez ces modifications et poussez-les vers votre dépôt GitHub.

Votre nouveau fichier de workflow GitHub Actions est maintenant installé dans votre dépôt et s’exécute automatiquement chaque fois que quelqu’un pousse (push) une modification vers le dépôt. Pour afficher les détails sur l’historique d’exécution d’un workflow, consultez « Affichage de l’activité pour une exécution de workflow ».

Présentation du fichier de workflow

Pour vous aider à comprendre comment la syntaxe YAML est utilisée pour créer un fichier de workflow, cette section explique chaque ligne de l’exemple d’introduction :

# Optional - The name of the workflow as it will appear in the "Actions" tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead.
name: learn-github-actions
# Optional - The name for workflow runs generated from the workflow, which will appear in the list of workflow runs on your repository's "Actions" tab. This example uses an expression with the `github` context to display the username of the actor that triggered the workflow run. For more information, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#run-name)."
run-name: ${{ github.actor }} is learning GitHub Actions

# Specifies the trigger for this workflow. This example uses the `push` event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request.  This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)."
on: [push]

# Groups together all the jobs that run in the `learn-github-actions` workflow.
jobs:

# Defines a job named `check-bats-version`. The child keys will define properties of the job.
  check-bats-version:

# Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on)"
    runs-on: ubuntu-latest

# Groups together all the steps that run in the `check-bats-version` job. Each item nested under this section is a separate action or shell script.
    steps:

# The `uses` keyword specifies that this step will run `v4` of the `actions/checkout` action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will use the repository's code.
      - uses: actions/checkout@v4

# This step uses the `actions/setup-node@v4` action to install the specified version of the Node.js. (This example uses version 14.) This puts both the `node` and `npm` commands in your `PATH`.
      - uses: actions/setup-node@v4
        with:
          node-version: '14'

# The `run` keyword tells the job to execute a command on the runner. In this case, you are using `npm` to install the `bats` software testing package.
      - run: npm install -g bats

# Finally, you'll run the `bats` command with a parameter that outputs the software version.
      - run: bats -v

name: learn-github-actions

run-name: ${{ github.actor }} is learning GitHub Actions

on: [push]

jobs:

  check-bats-version:

    runs-on: ubuntu-latest

    steps:

      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '14'

      - run: npm install -g bats

      - run: bats -v

# Optional - The name of the workflow as it will appear in the "Actions" tab of the GitHub repository. If this field is omitted, the name of the workflow file will be used instead.
name: learn-github-actions
# Optional - The name for workflow runs generated from the workflow, which will appear in the list of workflow runs on your repository's "Actions" tab. This example uses an expression with the `github` context to display the username of the actor that triggered the workflow run. For more information, see "[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#run-name)."
run-name: ${{ github.actor }} is learning GitHub Actions

# Specifies the trigger for this workflow. This example uses the `push` event, so a workflow run is triggered every time someone pushes a change to the repository or merges a pull request.  This is triggered by a push to every branch; for examples of syntax that runs only on pushes to specific branches, paths, or tags, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)."
on: [push]

# Groups together all the jobs that run in the `learn-github-actions` workflow.
jobs:

# Defines a job named `check-bats-version`. The child keys will define properties of the job.
  check-bats-version:

# Configures the job to run on the latest version of an Ubuntu Linux runner. This means that the job will execute on a fresh virtual machine hosted by GitHub. For syntax examples using other runners, see "[AUTOTITLE](/actions/reference/workflow-syntax-for-github-actions#jobsjob_idruns-on)"
    runs-on: ubuntu-latest

# Groups together all the steps that run in the `check-bats-version` job. Each item nested under this section is a separate action or shell script.
    steps:

# The `uses` keyword specifies that this step will run `v4` of the `actions/checkout` action. This is an action that checks out your repository onto the runner, allowing you to run scripts or other actions against your code (such as build and test tools). You should use the checkout action any time your workflow will use the repository's code.
      - uses: actions/checkout@v4

# This step uses the `actions/setup-node@v4` action to install the specified version of the Node.js. (This example uses version 14.) This puts both the `node` and `npm` commands in your `PATH`.
      - uses: actions/setup-node@v4
        with:
          node-version: '14'

# The `run` keyword tells the job to execute a command on the runner. In this case, you are using `npm` to install the `bats` software testing package.
      - run: npm install -g bats

# Finally, you'll run the `bats` command with a parameter that outputs the software version.
      - run: bats -v

Visualisation du fichier de workflow

Dans ce diagramme, vous pouvez voir le fichier de workflow que vous venez de créer et comment les composants GitHub Actions sont organisés dans une hiérarchie. Chaque étape exécute une action ou un script d’interpréteur de commandes unique. Les étapes 1 et 2 exécutent des actions, tandis que les étapes 3 et 4 exécutent des scripts d’interpréteur de commandes. Pour trouver d’autres actions prédéfinies pour vos workflows, consultez « Recherche et personnalisation d’actions ».

Affichage de l’activité pour une exécution de workflow

Lorsque votre workflow est déclenché, une exécution de workflow est créée et exécute le workflow. Une fois l’exécution de votre workflow démarrée, vous pouvez voir un graphe de visualisation de la progression de l’exécution, ainsi que l’activité de chaque étape sur GitHub.

1. Dans votre instance GitHub Enterprise Server, accédez à la page principale du dépôt.

2. Sous le nom de votre dépôt, cliquez sur Actions.

   

3. Dans la barre latérale gauche, cliquez sur le workflow que vous souhaitez afficher.

   

4. Dans la liste des exécutions de workflow, cliquez sur le nom de l’exécution pour voir le résumé de l’exécution du workflow.

5. Dans la barre latérale à gauche ou dans le graphe de visualisation, cliquez sur le travail que vous souhaitez voir.

6. Pour voir les résultats d’une étape, cliquez sur l’étape.

Pour plus d’informations sur la gestion des exécutions de workflow, telles que la réexécution, l’annulation ou la suppression d’une exécution de workflow, consultez « Gestion des exécutions de workflow ».

Utilisation de workflows de démarrage

GitHub fournit des workflows de démarrage préconfiguré que vous pouvez personnaliser pour créer votre propre workflow d’intégration continue. GitHub Enterprise Server analyse votre code et affiche des workflows de démarrage CI 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. Vous pouvez utiliser des workflows de démarrage comme point de départ pour créer votre workflow personnalisé, ou les utiliser en l’état.

Vous pouvez parcourir la liste complète des workflows de démarrage dans le référentiel actions/starter-workflows sur votre instance GitHub Enterprise Server.

Pour plus d’informations sur l’utilisation et la création de workflows de démarrage, consultez « Utilisation de workflows de démarrage » et « Création de workflows de démarrage pour votre organisation ».

Fonctionnalités de workflow avancées

Cet section décrit brièvement certaines des fonctionnalités avancées de GitHub Actions qui vous aident à créer des workflows plus complexes.

Stockage des secrets

Si vos workflows utilisent des données sensibles, telles que des mots de passe ou des certificats, vous pouvez les enregistrer dans GitHub en tant que secrets, puis les utiliser dans vos workflows en tant que variables d’environnement. Cela signifie que vous pourrez créer et partager des workflows sans avoir à incorporer des valeurs sensibles directement dans la source YAML du workflow.

Cet exemple de travail montre comment référencer un secret existant en tant que variable d’environnement et l’envoyer en tant que paramètre à un exemple de commande.

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

Pour plus d’informations, consultez « Utilisation de secrets dans GitHub Actions ».

Création de travaux dépendants

Par défaut, les travaux de votre workflow s’exécutent simultanément en parallèle. Si vous avez un travail qui doit s’exécuter uniquement une fois qu’un autre travail est terminé, vous pouvez utiliser le mot clé needs pour créer cette dépendance. Si l’un des travaux échoue, tous les travaux dépendants sont ignorés. Toutefois, si vous avez besoin que les travaux continuent, vous pouvez le définir à l’aide de l’instruction conditionnelle if.

Dans cet exemple, les travaux setup, build et test s’exécutent en série, avec build et test dépendants de la réussite du travail qui les précède :

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

Pour plus d’informations, consultez « Utilisation de travaux dans un workflow ».

Utilisation d’une matrice

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. La matrice est créée à l’aide du mot clé strategy, qui reçoit les options de génération sous forme de tableau. Par exemple, cette matrice exécute le travail plusieurs fois, à l’aide de différentes versions de Node.js :

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

Pour plus d’informations, consultez « Utilisation d’une matrice pour vos travaux ».

Mise en cache des dépendances

Si vos travaux réutilisent régulièrement les dépendances, vous pouvez envisager de mettre en cache ces fichiers pour améliorer les performances. Une fois le cache créé, il est disponible pour tous les workflows dans le même dépôt.

Cet exemple montre comment mettre en cache le répertoire ~/.npm :

jobs:
  example-job:
    steps:
      - name: Cache node modules
        uses: actions/cache@v3
        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 }}-

Pour plus d’informations, consultez « Mise en cache des dépendances pour accélérer les workflows ».

Utilisation de bases de données et de conteneurs de service

Si votre travail nécessite un service de base de données ou de cache, vous pouvez utiliser le mot clé services pour créer un conteneur éphémère afin d’héberger le service. Le conteneur obtenu est ensuite disponible pour toutes les étapes de ce travail et est supprimé une fois le travail terminé. Cet exemple montre comment un travail peut utiliser services pour créer un conteneur postgres, puis utiliser node pour se connecter au service.

jobs:
  container-job:
    runs-on: ubuntu-latest
    container: node:10.18-jessie
    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

Pour plus d’informations, consultez « Utilisation des services conteneurisés ».

Utilisation d’étiquettes pour router des workflows

Si vous souhaitez vous assurer qu’un type particulier d’exécuteur traitera votre travail, vous pouvez utiliser des étiquettes pour contrôler l’emplacement d’exécution des travaux. Vous pouvez affecter des étiquettes à un exécuteur auto-hébergé en plus de son étiquette par défaut self-hosted. Vous pouvez ensuite faire référence à ces étiquettes dans votre flux de travail YAML, ce qui garantit que le travail est routé de manière prévisible. Les exécuteurs hébergés par GitHub ont des étiquettes prédéfinies qui leur sont affectées.

Cet exemple montre comment un workflow peut utiliser des étiquettes pour spécifier l’exécuteur requis :

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

Un workflow s’exécute uniquement sur un exécuteur qui a toutes les étiquettes du tableau runs-on. Le travail va de préférence vers un exécuteur auto-hébergé inactif disposant des étiquettes spécifiées.

Pour en savoir plus sur les étiquettes d’exécuteur auto-hébergé, consultez « Utilisation d’étiquettes avec des exécuteurs auto-hébergés ».

Réutilisation des 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 ».

Renforcement de la sécurité pour les flux de travail

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

Utilisation des environnements

Vous pouvez configurer des environnements avec des règles de protection et des secrets pour contrôler l’exécution des travaux dans un workflow. Chaque travail d’un workflow peut référencer un seul environnement. Toutes les règles de protection configurées pour l’environnement doivent être validées pour qu’un travail référençant l’environnement soit envoyé à un exécuteur. Pour plus d’informations, consultez « Utilisation d’environnements pour le déploiement ».