infra / github-actions

Triggers avancés

Leçon 31 exercice

Explication

Ce que vous allez apprendre

Filtrer un déclenchement par branche, tag ou chemin de fichier modifié
Déclencher un workflow manuellement avec workflow_dispatch et un formulaire typé
Planifier une tâche récurrente avec schedule et la syntaxe cron
Rendre un workflow appelable depuis un autre avec workflow_call
Choisir le bon déclencheur selon l'intention réelle, plutôt que réagir à tout par défaut

Dans quel contexte ?

Un projet a un workflow de build qui se déclenche sur on: push, sans aucun filtre. Chaque fois qu'un contributeur corrige une simple faute de frappe dans le README.md, le pipeline complet se relance : installation des dépendances, tests, build de l'image Docker, plusieurs minutes de calcul pour un changement qui n'affecte pourtant aucun comportement du code. Cette leçon montre comment filtrer précisément quand un workflow doit réellement se déclencher, et comment ajouter des déclenchements alternatifs (manuel, planifié, appelable) pour des besoins qui ne collent pas au simple "à chaque push".

Le déclencheur le plus basique

D'abord, la première leçon a montré on: push comme déclencheur le plus basique.

Ce que ce réflexe coûte en ressources

Mais lancer un pipeline complet à chaque changement, quel qu'il soit, gaspille du temps et des ressources : pourquoi relancer des tests si seule la documentation a changé ?

La question à se poser systématiquement

Pourquoi construire l'application à chaque commit sur toutes les branches personnelles ? Les triggers avancés permettent d'être beaucoup plus précis sur quand et pourquoi un workflow doit réellement se déclencher.

Filtrer plutôt que subir

Les filtres par branche, par tag, ou par chemin de fichier modifié affinent le déclenchement pour qu'il corresponde à une intention réelle.

Trigger	Usage typique
`push` avec `paths:`	Ne réagir qu'aux changements de code source, pas à la doc
`schedule`	Tâche planifiée récurrente (syntaxe cron, en UTC)
`workflow_dispatch`	Déclenchement manuel avec formulaire typé dans l'UI GitHub
`workflow_call`	Rendre un workflow appelable comme une fonction depuis un autre

Des exemples concrets de ce filtrage

Ne réagir qu'aux changements de code source, ignorer les changements de documentation seule, ne construire une image que lors d'un tag de version. C'est un principe d'efficacité souvent négligé au démarrage d'un projet.

Bonne pratique

Ajoute systématiquement paths-ignore: ["**/*.md"] (ou l'inverse, paths: ciblé sur src/**) à un workflow de build coûteux. C'est un des réglages qui économise le plus de minutes CI pour le moins d'effort de configuration.

Sortir du réflexe "automatique uniquement"

Tous les workflows n'ont pas vocation à se déclencher tout seuls. workflow_dispatch introduit un déclenchement manuel, avec un vrai formulaire dans l'interface GitHub.

Un cas d'usage pour ce déclenchement manuel

C'est pratique pour des actions qui nécessitent une décision humaine consciente, comme un déploiement en production ponctuel, plutôt qu'une réaction automatique à un simple push.

Un autre déclencheur, pour un besoin différent

schedule, à l'inverse, automatise des tâches qui n'ont rien à voir avec un changement de code, comme une tâche de maintenance nocturne récurrente.

Piège fréquent

schedule utilise la syntaxe cron classique, exprimée en UTC, et n'est pas garanti de se déclencher à la seconde précise : en cas de forte charge sur l'infrastructure GitHub, l'exécution peut être retardée de plusieurs minutes, voire plus rarement sautée. Ne t'appuie jamais dessus pour une tâche qui exige une précision absolue.

Composer des workflows entre eux

workflow_call introduit une idée nouvelle et puissante : un workflow peut devenir une sorte de "fonction" appelable depuis un autre workflow, avec ses propres paramètres d'entrée.

Le bénéfice de cette composition

C'est un principe de réutilisation qui évite de dupliquer la même logique de déploiement dans dix fichiers différents, un sujet développé plus loin dans le cours.

Maintenant que tu sais déclencher précisément un workflow, la leçon suivante s'attaque à la coordination entre plusieurs jobs d'un même workflow.

Commandes & code

Triggers avancés

name: Advanced Triggers
on:
  push:
    branches: [main, "release/**"]
    tags: ["v*.*.*"]
    paths:
      - "src/**"
      - "!src/**/*.md"          # ignore les changements de doc dans src/

  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]
    branches: [main]

  schedule:
    - cron: "0 3 * * 1-5"        # 03h00 UTC, du lundi au vendredi (syntaxe cron classique)

  workflow_dispatch:              # déclenchement manuel depuis l'UI GitHub ou gh CLI
    inputs:
      environment:
        description: "Environnement cible"
        required: true
        default: "staging"
        type: choice
        options: [staging, production]
      skip_tests:
        description: "Ignorer les tests (urgence uniquement)"
        type: boolean
        default: false

  workflow_call:                  # rend ce workflow appelable depuis un autre (voir leçon reusable)
    inputs:
      version:
        required: true
        type: string

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Déploiement vers ${{ inputs.environment }}"
        if: github.event_name == 'workflow_dispatch'

# Déclencher manuellement un workflow_dispatch depuis le terminal
gh workflow run deploy.yml -f environment=production -f skip_tests=false

# Vérifier les prochaines exécutions planifiées (schedule)
gh workflow view nightly.yml

# Filtrer une PR selon son état (utile pour ignorer les brouillons)
jobs:
  ci:
    if: github.event.pull_request.draft == false
    runs-on: ubuntu-latest

Trigger	Déclenché par
`push`	Un commit poussé sur une branche/tag surveillée
`pull_request`	Ouverture, mise à jour, réouverture d'une PR
`schedule`	Cron planifié (attention : peut être retardé en cas de forte charge GitHub)
`workflow_dispatch`	Déclenchement manuel, avec paramètres typés
`workflow_call`	Appel depuis un autre workflow (composition)

Résumé

paths:/paths-ignore: évitent de lancer un job pour un changement non pertinent (docs seules).
schedule utilise la syntaxe cron, en UTC, avec un délai possible en cas de charge élevée.
workflow_dispatch.inputs crée un formulaire de déclenchement manuel typé dans l'UI GitHub.
workflow_call transforme un workflow en "fonction" appelable depuis d'autres workflows.

Exercices pratiques

1 disponible

Mission : un pipeline qui se déclenche pour un README

Objectif : Filtrer les déclenchements inutiles d'un workflow et ajouter un déclenchement manuel typé ainsi qu'une tâche planifiée.

Contexte

Le workflow build.yml d'un projet se déclenche sur on: push, sans aucun filtre. Chaque correction de faute de frappe dans README.md relance un build complet de plusieurs minutes. L'équipe veut aussi pouvoir déclencher un déploiement manuel vers staging ou production depuis l'interface GitHub, avec un vrai formulaire, et planifier une tâche de maintenance nocturne.

Résoudre l’exercice →