Exercice 02 : Configurer les déclencheurs (on:)

🎯 Objectifs

À la fin de cet exercice, vous serez capable de :

✅ Restreindre on: push à des branches spécifiques
✅ Utiliser on: pull_request pour automatiser les revues
✅ Planifier un workflow avec on: schedule (syntaxe cron)
✅ Déclencher manuellement avec on: workflow_dispatch
✅ Combiner plusieurs déclencheurs dans un seul workflow

Durée estimée : 15 min | Difficulté : ⭐⭐☆☆☆

📖 Contexte

Le champ on: contrôle quand un workflow s'exécute. C'est l'une des décisions les plus importantes en CI/CD : déclencher trop souvent gaspille des ressources, trop rarement ralentit la détection des régressions.

GitHub Actions propose des dizaines d'événements. Les plus courants :

Événement	Cas d'usage
`push`	Validation de code à chaque commit
`pull_request`	Vérification avant fusion
`schedule`	Tâches planifiées (rapports, nettoyages)
`workflow_dispatch`	Déclenchement manuel (déploiements)

📋 Énoncé

Vous allez créer plusieurs fichiers workflow dans votre repository pour explorer chaque type de déclencheur. Chaque workflow affichera simplement un message indiquant comment il a été déclenché.

🧭 Déroulement

Tâche 1 : Push sur des branches spécifiques

Créez .github/workflows/push-branches.yml. Configurez on: push pour que le workflow ne se déclenche que sur les branches main et develop, et non sur les autres branches.

Indice :
`yaml
on:
push:
branches:
- main
- develop
`
Vous pouvez aussi utiliser des patterns glob : feature/** correspondra à toutes les branches commençant par feature/.

Vérification : Un push sur une branche fix/bug-123 ne déclenche pas ce workflow. Un push sur main le déclenche.

Tâche 2 : Déclencheur pull_request

Créez .github/workflows/pr-check.yml. Configurez le workflow pour qu'il se déclenche sur les événements pull_request de type opened et synchronize (nouveaux commits sur une PR ouverte).

Indice :
`yaml
on:
pull_request:
types: [opened, synchronize]
`
Sans types:, pull_request se déclenche sur opened, synchronize et reopened par défaut.

Vérification : Ouvrez une PR sur GitHub - le workflow apparaît dans la liste des checks de la PR.

Tâche 3 : Planification avec schedule (cron)

Créez .github/workflows/nightly.yml. Configurez un workflow qui s'exécute automatiquement tous les jours à 2h00 du matin UTC.

Indice :
`yaml
on:
schedule:
- cron: '0 2 * * *'
`
Format cron : minute heure jour-du-mois mois jour-de-la-semaine. L'outil crontab.guru aide à construire les expressions.

Vérification : Le fichier YAML est valide. Le prochain déclenchement est visible dans l'onglet Actions une fois le workflow poussé.

Tâche 4 : Déclenchement manuel avec workflow_dispatch

Créez .github/workflows/manuel.yml. Configurez on: workflow_dispatch et ajoutez un paramètre d'entrée environnement de type choice avec les options staging et production.

Indice :
`yaml
on:
workflow_dispatch:
inputs:
environnement:
description: "Environnement cible"
required: true
type: choice
options:
- staging
- production
`
Une fois poussé, un bouton "Run workflow" apparaît dans l'onglet Actions.

Vérification : L'onglet Actions affiche un bouton "Run workflow" pour ce workflow. Vous pouvez sélectionner staging ou production avant de lancer.

Tâche 5 : Combiner plusieurs déclencheurs

Créez .github/workflows/multi-trigger.yml. Ce workflow doit se déclencher sur :

push vers main
pull_request vers main
Manuellement via workflow_dispatch

Indice : Listez plusieurs événements sous on: :
`yaml
on:
push:
branches: [main]
pull_request:
branches: [main]
workflow_dispatch:
`

Vérification : Le workflow s'exécute dans les 3 scénarios : push sur main, ouverture d'une PR, et déclenchement manuel.

🗂️ Mini-Projet

Créez un workflow hebdomadaire.yml qui :

Se déclenche chaque lundi à 8h00 UTC
Peut aussi être lancé manuellement
Affiche la date du rapport et le message "Rapport hebdomadaire généré"

yaml

# Checkpoints à valider :
# [ ] on: push avec filtrage de branches fonctionne
# [ ] on: pull_request apparaît dans les checks d'une PR
# [ ] on: schedule contient une expression cron valide
# [ ] on: workflow_dispatch affiche un bouton "Run workflow"
# [ ] Un workflow combine au moins 2 déclencheurs
# [ ] Bonus : workflow hebdomadaire créé avec schedule + workflow_dispatch

Exercice 02 : Configurer les déclencheurs (on:)

🎯 Objectifs

À la fin de cet exercice, vous serez capable de :

✅ Restreindre on: push à des branches spécifiques
✅ Utiliser on: pull_request pour automatiser les revues
✅ Planifier un workflow avec on: schedule (syntaxe cron)
✅ Déclencher manuellement avec on: workflow_dispatch
✅ Combiner plusieurs déclencheurs dans un seul workflow

Durée estimée : 15 min | Difficulté : ⭐⭐☆☆☆

📖 Contexte

GitHub Actions propose des dizaines d'événements. Les plus courants :

Événement	Cas d'usage
`push`	Validation de code à chaque commit
`pull_request`	Vérification avant fusion
`schedule`	Tâches planifiées (rapports, nettoyages)
`workflow_dispatch`	Déclenchement manuel (déploiements)

📋 Énoncé

🧭 Déroulement

Tâche 1 : Push sur des branches spécifiques

Créez .github/workflows/push-branches.yml. Configurez on: push pour que le workflow ne se déclenche que sur les branches main et develop, et non sur les autres branches.

Indice :
`yaml
on:
push:
branches:
- main
- develop
`
Vous pouvez aussi utiliser des patterns glob : feature/** correspondra à toutes les branches commençant par feature/.

Vérification : Un push sur une branche fix/bug-123 ne déclenche pas ce workflow. Un push sur main le déclenche.

Tâche 2 : Déclencheur pull_request

Créez .github/workflows/pr-check.yml. Configurez le workflow pour qu'il se déclenche sur les événements pull_request de type opened et synchronize (nouveaux commits sur une PR ouverte).

Indice :
`yaml
on:
pull_request:
types: [opened, synchronize]
`
Sans types:, pull_request se déclenche sur opened, synchronize et reopened par défaut.

Vérification : Ouvrez une PR sur GitHub - le workflow apparaît dans la liste des checks de la PR.

Tâche 3 : Planification avec schedule (cron)

Créez .github/workflows/nightly.yml. Configurez un workflow qui s'exécute automatiquement tous les jours à 2h00 du matin UTC.

Indice :
`yaml
on:
schedule:
- cron: '0 2 * * *'
`
Format cron : minute heure jour-du-mois mois jour-de-la-semaine. L'outil crontab.guru aide à construire les expressions.

Vérification : Le fichier YAML est valide. Le prochain déclenchement est visible dans l'onglet Actions une fois le workflow poussé.

Tâche 4 : Déclenchement manuel avec workflow_dispatch

Créez .github/workflows/manuel.yml. Configurez on: workflow_dispatch et ajoutez un paramètre d'entrée environnement de type choice avec les options staging et production.

Indice :
`yaml
on:
workflow_dispatch:
inputs:
environnement:
description: "Environnement cible"
required: true
type: choice
options:
- staging
- production
`
Une fois poussé, un bouton "Run workflow" apparaît dans l'onglet Actions.

Vérification : L'onglet Actions affiche un bouton "Run workflow" pour ce workflow. Vous pouvez sélectionner staging ou production avant de lancer.

Tâche 5 : Combiner plusieurs déclencheurs

Créez .github/workflows/multi-trigger.yml. Ce workflow doit se déclencher sur :

push vers main
pull_request vers main
Manuellement via workflow_dispatch

Indice : Listez plusieurs événements sous on: :
`yaml
on:
push:
branches: [main]
pull_request:
branches: [main]
workflow_dispatch:
`

Vérification : Le workflow s'exécute dans les 3 scénarios : push sur main, ouverture d'une PR, et déclenchement manuel.

🗂️ Mini-Projet

Créez un workflow hebdomadaire.yml qui :

Se déclenche chaque lundi à 8h00 UTC
Peut aussi être lancé manuellement
Affiche la date du rapport et le message "Rapport hebdomadaire généré"

yaml

# Checkpoints à valider :
# [ ] on: push avec filtrage de branches fonctionne
# [ ] on: pull_request apparaît dans les checks d'une PR
# [ ] on: schedule contient une expression cron valide
# [ ] on: workflow_dispatch affiche un bouton "Run workflow"
# [ ] Un workflow combine au moins 2 déclencheurs
# [ ] Bonus : workflow hebdomadaire créé avec schedule + workflow_dispatch