À 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 :

Un ou plusieurs événements qui déclenchent le workflow.
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.
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 ».

Diagramme d’un événement déclenchant Exécuteur 1 pour exécuter Travail 1, lequel déclenche Exécuteur 2 pour exécuter Travail 2. Chacun des travaux est divisé en plusieurs étapes.

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.

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

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
on: [push]
jobs:
  check-bats-version:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: actions/setup-node@v3
        with:
          node-version: '14'
      - run: npm install -g bats
      - run: bats -v

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 :

`name: learn-github-actions`	Facultatif - Nom du workflow tel qu’il apparaît sous l’onglet Actions du référentiel GitHub.
`on: [push]`	Spécifie le déclencheur de ce workflow. Cet exemple utilise l’événement `push`, de sorte qu’une exécution de workflow est déclenchée chaque fois que quelqu’un pousse (push) une modification vers le référentiel ou fusionne une demande de tirage (pull request). Elle est déclenchée par un push vers chaque branche. Pour obtenir des exemples de syntaxe qui s’exécutent uniquement sur des push vers des branches, des chemins ou des étiquettes spécifiques, consultez « Syntaxe de workflow pour GitHub Actions ».
`jobs:`	Regroupe tous les travaux qui s’exécutent dans le workflow `learn-github-actions`.
`check-bats-version:`	Définit un travail nommé `check-bats-version`. Les clés enfants définissent les propriétés du travail.
`runs-on: ubuntu-latest`	Configure le travail à exécuter sur la dernière version d’un exécuteur Ubuntu Linux. Cela signifie que le travail s’exécutera sur une nouvelle machine virtuelle hébergée par GitHub. Pour obtenir des exemples de syntaxe utilisant d’autres exécuteurs, consultez « Syntaxe de workflow pour GitHub Actions ».
`steps:`	Regroupe toutes les étapes qui s’exécutent dans le travail `check-bats-version`. Chaque élément imbriqué sous cette section est une action ou un script d’interpréteur de commandes distinct.
`- uses: actions/checkout@v3`	Le mot clé `uses` spécifie que cette étape exécute la version `v3` de l’action `actions/checkout`. Il s’agit d’une action qui extrait votre dépôt sur l’exécuteur, ce qui vous permet d’exécuter des scripts ou d’autres actions sur votre code (telles que des outils de génération et de test). Vous devez utiliser l’action d’extraction chaque fois que votre workflow s’exécutera sur le code du dépôt.
`- uses: actions/setup-node@v3 with: node-version: '14'`	Cette étape utilise l’action `actions/setup-node@v3` pour installer la version spécifiée de Node.js (cet exemple utilise v14). Cela place les deux commandes `node` et `npm` dans votre `PATH`.
`- run: npm install -g bats`	Le mot clé `run` indique au travail d’exécuter une commande sur l’exécuteur. Dans ce cas, vous utilisez `npm` pour installer le package de test logiciel `bats`.
`- run: bats -v`	Enfin, vous allez exécuter la commande `bats` avec un paramètre qui génère la version logicielle.

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

Diagramme montrant le déclencheur, l’exécuteur et le travail d’un workflow. Le travail est divisé en 4 étapes.

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.

Dans votre instance GitHub Enterprise Server, accédez à la page principale du dépôt. 1. Sous le nom de votre dépôt, cliquez sur Actions.

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

1. 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.
Dans la barre latérale à gauche ou dans le graphe de visualisation, cliquez sur le travail que vous souhaitez voir.
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 « Secrets chiffrés ».

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: [12, 14, 16]
    steps:
      - uses: actions/setup-node@v3
        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@v3
      - 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. Ensuite, vous pouvez faire référence à ces étiquettes dans votre workflow YAML, en vous assurant que le travail est routé de manière prévisible. Des étiquettes prédéfinies sont affectées aux exécuteurs hébergés par GitHub.

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

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

À propos des workflows

Dans cet article