act promet d’exécuter un workflow GitHub Actions directement en local, dans un conteneur Docker, sans pousser le moindre commit. L’intérêt est évident pour itérer sur un fichier .yml capricieux sans polluer l’historique de commits de tentatives-erreurs. Sur un projet WordPress d’agence avec quinze workflows différents (tests PHPUnit, lint PHPCS, build de blocs, déploiement), nous avons comparé systématiquement le comportement local via act et le comportement du même workflow exécuté réellement sur les runners hébergés de GitHub.
Le résultat n’est ni un franc succès ni un échec total : act reproduit fidèlement la logique d’orchestration des étapes, mais plusieurs écarts d’environnement peuvent masquer ou au contraire provoquer de faux échecs, qu’il faut savoir reconnaître avant de faire confiance aveuglément à une exécution locale verte.
Ce qui fonctionne de façon fiable
La logique de dépendance entre jobs, les conditions if:, les matrices de version, et l’enchaînement des étapes (steps) se comportent de manière identique entre act et un vrai runner. Un workflow mal formé, avec une dépendance circulaire entre jobs ou une syntaxe de matrice invalide, échoue de la même façon dans les deux environnements, ce qui couvre déjà l’essentiel des erreurs de configuration les plus fréquentes.
Tableau des écarts constatés
| Aspect | Comportement sous act | Comportement sur GitHub réel |
|---|---|---|
| Image de runner par défaut | Image réduite node:16-buster-slim sauf configuration explicite | Image complète Ubuntu avec de nombreux outils préinstallés |
| Secrets de dépôt | Doivent être fournis manuellement via --secret-file | Injectés automatiquement depuis les réglages du dépôt |
Cache d’actions (actions/cache) | Simulé localement, non partagé entre exécutions comme sur GitHub | Persisté entre exécutions via le service de cache GitHub |
| Durée d’exécution | Souvent plus rapide, réseau local | Variable selon la charge des runners partagés |
| Services (bases de données, etc.) | Fonctionnent via Docker Compose interne, généralement fiables | Fonctionnent nativement, référence de comportement |
L’écart qui a produit un faux négatif chez nous
Sur notre workflow de lint PHPCS, l’exécution sous act passait au vert alors que la même exécution sur GitHub échouait sur une règle de compatibilité PHP 8.1. La cause : l’image réduite utilisée par défaut par act embarquait une version de PHP différente de celle spécifiée dans le workflow, faute d’avoir précisé l’image complète correspondante :
# .actrc, à la racine du projet
-P ubuntu-latest=catthehacker/ubuntu:act-latestAprès avoir forcé cette image plus proche de celle réellement utilisée par GitHub, l’écart a disparu. Sans cette configuration explicite, un test qui passe sous act ne garantit rien sur le comportement réel du pipeline.
L’écart qui a produit un faux positif
À l’inverse, un workflow de build de blocs Gutenberg échouait systématiquement sous act à cause de secrets manquants (jeton d’accès à un registre npm privé), non fournis par défaut, alors que le même workflow réussissait normalement sur GitHub où le secret est injecté automatiquement. Il faut alimenter act explicitement :
act -j build-blocs --secret-file .secrets.localVerdict : utile pour itérer, jamais suffisant pour valider
act reste précieux pour corriger rapidement une syntaxe de workflow ou déboguer une étape sans attendre le cycle complet de push-attente-lecture-des-logs sur GitHub. Il ne doit jamais remplacer une exécution réelle avant de considérer un workflow comme validé : les écarts d’image, de secrets et de cache sont trop fréquents pour s’y fier aveuglément. Notre pratique actuelle est d’itérer localement avec act jusqu’à obtenir un résultat stable, puis de confirmer systématiquement par un vrai push sur une branche de test avant de considérer le travail terminé.
Pour aller plus loin
Ce comparatif suppose une configuration de GitHub Actions déjà fonctionnelle par ailleurs ; il ne traite pas de la mise en place initiale des workflows eux-mêmes, seulement de la fiabilité de leur simulation locale une fois écrits.
