Un plugin distribué sur le répertoire officiel de WordPress, ou vendu à plusieurs clients hébergés différemment, doit fonctionner sur un éventail de configurations bien plus large que le seul poste du développeur qui l’a écrit. PHP 7.4 chez un hébergeur, PHP 8.0 chez un autre, WordPress à jour d’un côté, WordPress en retard de deux versions mineures de l’autre : chaque combinaison peut révéler un comportement différent. GitHub Actions permet de tester toutes ces combinaisons automatiquement, à chaque push, grâce à son système de matrice.
Cet article détaille la construction d’un workflow GitHub Actions complet pour une suite PHPUnit WordPress, avec base de données MySQL en service, cache Composer, et une matrice qui croise plusieurs versions de PHP et de WordPress.
Structure de base du workflow
Un workflow GitHub Actions se définit dans un fichier YAML sous .github/workflows/. La structure de base pour une suite PHPUnit WordPress ressemble à ceci :
name: Tests PHPUnit
on:
push:
branches: [ main ]
pull_request:
branches: [ main ]
jobs:
phpunit:
runs-on: ubuntu-latest
services:
mysql:
image: mysql:5.7
env:
MYSQL_ROOT_PASSWORD: root
MYSQL_DATABASE: wordpress_test
ports:
- 3306:3306
options: --health-cmd="mysqladmin ping" --health-interval=10s --health-timeout=5s --health-retries=3Le service MySQL démarre en parallèle du job, dans un conteneur Docker géré directement par GitHub Actions, avec une vérification de santé qui attend que la base soit réellement prête à accepter des connexions avant de continuer.
Construire la matrice de versions
La section strategy.matrix permet de déclarer plusieurs axes de variation, que GitHub Actions combine automatiquement pour exécuter un job par combinaison :
strategy:
fail-fast: false
matrix:
php: [ '7.4', '8.0', '8.1' ]
wordpress: [ '5.9', '6.0' ]Avec trois versions de PHP et deux versions de WordPress, GitHub Actions exécute automatiquement six jobs en parallèle, chacun avec sa propre combinaison. L’option fail-fast: false est importante : sans elle, GitHub Actions annule les jobs restants dès qu’une combinaison échoue, ce qui masque des informations utiles sur les autres combinaisons.
Installer PHP et les dépendances par combinaison
steps:
- uses: actions/checkout@v3
- name: Installer PHP ${{ matrix.php }}
uses: shivammathur/setup-php@v2
with:
php-version: ${{ matrix.php }}
extensions: mysqli
coverage: none
- name: Cache des dépendances Composer
uses: actions/cache@v3
with:
path: vendor
key: composer-${{ matrix.php }}-${{ hashFiles('composer.lock') }}
- name: Installer les dépendances
run: composer install --prefer-dist --no-progressLe cache Composer, indexé à la fois sur la version de PHP et sur le hash du fichier composer.lock, évite de retélécharger les mêmes paquets à chaque exécution tant que les dépendances n’ont pas changé. Sur un projet avec une dizaine de dépendances de développement, ce cache divise souvent par deux ou trois le temps total du job.
Installer WordPress à la version demandée
Le script bin/install-wp-tests.sh, généré par wp scaffold plugin-tests, accepte la version de WordPress en dernier paramètre. On l’appelle en réutilisant la variable de matrice :
- name: Installer l'environnement de test WordPress
run: bash bin/install-wp-tests.sh wordpress_test root root 127.0.0.1 ${{ matrix.wordpress }}
- name: Lancer PHPUnit
run: vendor/bin/phpunitNotez l’utilisation de 127.0.0.1 plutôt que localhost pour l’hôte MySQL : dans certains environnements Docker, localhost tente une connexion par socket Unix plutôt que par le port exposé, ce qui échoue silencieusement face à un service MySQL démarré en conteneur.
Lire les résultats efficacement
Avec six combinaisons en parallèle, l’onglet Actions de GitHub affiche un résumé clair : chaque combinaison apparaît comme un job distinct, avec son propre statut. Un tableau récapitulatif aide à interpréter les priorités :
| Situation | Priorité |
|---|---|
| Échec sur toutes les combinaisons | Bug réel dans le code, à corriger immédiatement |
| Échec uniquement sur une version PHP ancienne | Vérifier la compatibilité descendante avant de publier |
| Échec uniquement sur une version WordPress récente | Anticiper une fonction dépréciée ou modifiée |
| Échec isolé, non reproductible localement | Suspecter un test instable plutôt qu’un vrai bug |
Sur nos projets distribués publiquement, nous gardons toujours au moins la version de PHP minimale annoncée dans l’en-tête du plugin dans la matrice. C’est la seule façon de garantir que la compatibilité affichée aux utilisateurs correspond à la réalité testée, et pas seulement à une intention.
En résumé
Une matrice GitHub Actions transforme une suite PHPUnit qui ne prouve la compatibilité que sur une seule configuration en une vérification systématique de toutes les combinaisons réellement utilisées par vos clients. Le coût, quelques minutes de calcul supplémentaires par push, reste négligeable comparé au temps perdu à diagnostiquer en production un bug de compatibilité qu’un job de matrice aurait détecté en quelques secondes.
