À 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 l’annuaire .github/workflows d’un dépôt. Un dépôt peut avoir plusieurs workflows, chacun pouvant effectuer un ensemble différent de travaux comme :

Création et test des demandes de tirage.
Déploiement de votre application à chaque création d’une version.
Ajout d’une étiquette chaque fois qu’un nouveau problème est ouvert.

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

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 et des déploiements de workflow ».

Utilisation de modèles de workflow

GitHub fournit des modèles de workflow préconfigurés que vous pouvez utiliser tels quels ou personnaliser pour créer votre propre workflow. GitHub Enterprise Server analyse votre code et vous affiche des modèles de workflow 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. Pour plus d’informations, consultez « Utilisation de modèles de workflow ».

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 « Exécution de variantes de tâches dans un workflow ».

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

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 « Gestion des environnements pour le déploiement ».

À propos des workflows

Dans cet article