# act contre un vrai runner GitHub Actions : la simulation locale tient-elle ?

> Comparatif entre l'exécution locale d'un workflow via act et une vraie exécution sur GitHub, avec les écarts constatés sur un projet WordPress réel.

- Auteur : Clément Hadrot
- Publié le : 2025-01-28
- Mis à jour le : 2025-01-28
- Catégorie : Tests
- URL : https://wpmoderne.dev.wordpress-developpement.fr/tests/act-contre-runner-github-actions-simulation/

## L’essentiel

- act exécute les workflows dans des conteneurs Docker locaux
- Les secrets et le cache GitHub natif ne sont pas reproduits fidèlement
- Un écart de version d'image peut masquer une vraie régression

[act](https://github.com/nektos/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

> L'essentiel à retenir : act exécute les workflows dans des conteneurs Docker locaux ; Les secrets et le cache GitHub natif ne sont pas reproduits fidèlement ; Un écart de version d'image peut masquer une vraie régression

| 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-latest
```

Aprè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.local
```

## Verdict : 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.