Après le premier pipeline GitHub Actions posé sur un projet, l’étape suivante inévitable est de le dupliquer sur le projet suivant, puis le suivant, jusqu’à se retrouver avec quinze fichiers .github/workflows/ci.yml quasiment identiques, dispersés dans quinze dépôts différents. Le jour où une étape doit changer (une nouvelle version de PHP à tester, un nouvel outil de lint à intégrer), il faut la recopier partout, avec le risque que certains dépôts restent à l’ancienne version sans qu’on s’en aperçoive.
Les workflows réutilisables de GitHub Actions (workflow_call) répondent précisément à ce problème : un workflow complet, écrit une seule fois dans un dépôt central, devient appelable depuis n’importe quel autre dépôt de l’organisation, avec des paramètres qui l’adaptent à chaque projet.
Le dépôt central de workflows
La première étape consiste à créer un dépôt dédié (par exemple agence/workflows-ci) qui contient uniquement des définitions de workflows réutilisables, sans code applicatif :
# agence/workflows-ci/.github/workflows/lint-et-tests-wordpress.yml
name: Lint et tests WordPress réutilisable
on:
workflow_call:
inputs:
version_php:
required: false
type: string
default: '8.2'
chemin_theme:
required: true
type: string
jobs:
qualite:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: shivammathur/setup-php@v2
with:
php-version: ${{ inputs.version_php }}
- name: Installer les dépendances PHP
run: composer install --no-interaction
working-directory: ${{ inputs.chemin_theme }}
- name: Lint PHP (PHPCS)
run: vendor/bin/phpcs
working-directory: ${{ inputs.chemin_theme }}
- name: Tests unitaires
run: composer test
working-directory: ${{ inputs.chemin_theme }}
Ce fichier déclare on: workflow_call plutôt que on: push, ce qui signale à GitHub qu’il ne s’exécute pas tout seul, mais uniquement lorsqu’un autre workflow l’appelle explicitement. Les inputs définissent les paramètres que chaque projet appelant pourra personnaliser.
L’appel depuis chaque projet client
Dans chaque dépôt de projet, il ne reste plus qu’un fichier minimal qui référence le workflow central par son chemin complet, avec le numéro de version ou de branche du dépôt central :
# dans le dépôt site-client-menuiserie, .github/workflows/ci.yml
name: CI
on:
pull_request:
branches: [main]
jobs:
qualite:
uses: agence/workflows-ci/.github/workflows/lint-et-tests-wordpress.yml@v1
with:
chemin_theme: wp-content/themes/theme-menuiserie
version_php: '8.3'
Le mot-clé uses pointe vers le workflow réutilisable, suivi d’un identifiant de version (@v1, un tag Git posé sur le dépôt central). C’est ce tag qui permet de figer la version du workflow utilisée par chaque projet, et de faire évoluer le dépôt central sans casser rétroactivement tous les projets qui ne sont pas encore passés sur la nouvelle version.
Versionner les évolutions du workflow central
Le vrai gain de cette organisation apparaît au moment de faire évoluer la logique commune. Ajouter une étape de vérification de sécurité (par exemple un scan de dépendances Composer connues comme vulnérables) se fait une seule fois, dans le dépôt central, puis se propage à tous les projets qui référencent la nouvelle version du tag :
git tag -a v2 -m "Ajout du scan de sécurité Composer"
git push origin v2
Chaque projet migre ensuite à son rythme, en changeant simplement @v1 en @v2 dans son propre fichier d’appel, plutôt que de recopier une nouvelle étape de workflow dans chaque dépôt.
Ce que cette organisation impose comme discipline
- Le dépôt central de workflows devient une dépendance critique pour tout le parc : une erreur introduite dedans affecte potentiellement tous les projets qui l’utilisent, ce qui impose de le tester soigneusement avant de publier un nouveau tag ;
- Les
inputsdoivent rester suffisamment génériques pour couvrir la diversité réelle des projets, sans multiplier les branches conditionnelles internes au workflow réutilisable, qui finiraient par le rendre aussi complexe à maintenir que la duplication qu’il visait à éviter ; - Les secrets utilisés par un workflow réutilisable doivent être transmis explicitement par le dépôt appelant via le mot-clé
secrets, ils ne sont jamais hérités automatiquement.
On ne fait évoluer le dépôt central de workflows qu’avec la même rigueur qu’un projet en production : une pull request relue, un tag de version explicite, jamais de modification directe d’un tag déjà utilisé par des projets clients.
En résumé
Les workflows réutilisables transforment une collection de fichiers CI dupliqués en un vrai composant partagé, versionné et testé une seule fois. Pour une agence qui gère plus de quelques projets WordPress avec une logique de qualité et de déploiement similaire, l’investissement initial pour centraliser cette logique se rentabilise dès la première évolution qui, sinon, aurait dû être recopiée manuellement dans chaque dépôt.
