À 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 ».
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 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.
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 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
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
-
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 :
Code | Explication |
---|---|
|
Facultatif - Nom du workflow tel qu’il apparaît sous l’onglet Actions du référentiel GitHub. |
|
Facultatif : nom des exécutions de workflow générées à partir du workflow, qui s’affiche dans la liste des exécutions de workflow sous l’onglet « Actions » de votre référentiel. Cet exemple utilise une expression avec le contexte |
|
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 ».
|
|
Regroupe tous les travaux qui s’exécutent dans le workflow learn-github-actions .
|
|
Définit un travail nommé check-bats-version . Les clés enfants définissent les propriétés du travail.
|
|
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 ». |
|
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.
|
|
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.
|
|
Cette étape utilise l’action actions/setup-node@v4 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 .
|
|
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 .
|
|
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 ».
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 GitHub.com, accédez à la page principale du dépôt.
-
Sous le nom de votre dépôt, cliquez sur Actions.
-
Dans la barre latérale gauche, cliquez sur le workflow que vous souhaitez afficher.
-
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 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.
Pour plus d’informations sur l’utilisation et la création de workflows de démarrage, consultez « Using starter workflows » 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
. 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. Si aucun n’est disponible et qu’il existe un exécuteur hébergé par GitHub disposant des étiquettes spécifiées, le travail va vers cet exécuteur hébergé par GitHub.
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 ».
Pour en savoir plus sur les étiquettes d’exécuteur hébergé par GitHub, consultez « Using GitHub-hosted runners ».
Réutilisation des workflows
Vous pouvez appeler 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 ».