# act pour exécuter vos workflows GitHub Actions en local avant de pousser

> Tester une modification de pipeline sans consommer de minutes CI ni attendre le retour du serveur distant, directement depuis son poste.

- Auteur : Clément Hadrot
- Publié le : 2022-09-15
- Mis à jour le : 2022-09-15
- Catégorie : Outils & workflow
- URL : https://wpmoderne.dev.wordpress-developpement.fr/outils/act-executer-workflows-github-actions-local/

## L’essentiel

- Exécute les workflows dans des conteneurs Docker locaux
- Gagne un cycle complet d'attente sur chaque test de pipeline
- Ne reproduit pas fidèlement 100 % de l'environnement GitHub

Modifier un fichier de workflow GitHub Actions suit traditionnellement un cycle frustrant : écrire une modification, committer, pousser, attendre que le pipeline se déclenche sur le serveur distant, découvrir une erreur de syntaxe ou de logique, corriger, recommencer. Chaque itération de ce cycle coûte du temps d'attente et des minutes CI consommées pour des essais qui n'ont souvent rien à voir avec le code applicatif lui-même. act permet de sortir de ce cycle en exécutant les mêmes workflows directement en local, dans des conteneurs Docker qui reproduisent l'environnement des runners GitHub.

Ce n'est pas un simple analyseur de syntaxe YAML : act exécute réellement chaque étape du workflow, avec les mêmes actions déclarées, ce qui permet de repérer aussi bien une erreur de configuration qu'un problème de logique dans les commandes exécutées.

## Installer act

```
brew install act
```

Sur Linux, un script d'installation officiel ou un paquet de gestionnaire de paquets fait l'affaire. act s'appuie sur Docker, qui doit donc déjà être installé et actif sur la machine.

## Lancer un workflow existant

> L'essentiel à retenir : Exécute les workflows dans des conteneurs Docker locaux ; Gagne un cycle complet d'attente sur chaque test de pipeline ; Ne reproduit pas fidèlement 100 % de l'environnement GitHub

Depuis la racine d'un dépôt contenant un dossier `.github/workflows`, une seule commande suffit à déclencher l'événement correspondant à un push :

```
act push
```

act détecte automatiquement les workflows configurés pour réagir à cet événement et les exécute localement, étape par étape, avec un affichage similaire à celui de l'interface GitHub :

```
[CI/build] 🚀  Start image=catthehacker/ubuntu:act-latest
[CI/build]   ✅  Success - Checkout
[CI/build]   ✅  Success - Installer les dépendances Composer
[CI/build]   ❌  Failure - Lancer les tests PHPUnit
```

## Simuler d'autres événements

act peut simuler différents déclencheurs, y compris une pull request ou un événement planifié, ce qui est utile pour tester un workflow qui ne se déclenche pas sur un simple push :

```
act pull_request
act workflow_dispatch
act schedule
```

## Gérer les secrets en local

Un workflow qui dépend de secrets d'environnement (une clé API de test, un jeton d'accès) ne peut évidemment pas accéder aux secrets réels stockés côté GitHub. act accepte un fichier local pour simuler ces valeurs, à exclure impérativement du versionnement :

```
act push --secret-file .secrets.local

# .secrets.local
API_KEY=valeur-de-test-locale
```

## Les limites de fidélité à connaître

- Les images Docker utilisées par act ne sont pas rigoureusement identiques aux images des runners GitHub réels : certains paquets système préinstallés côté GitHub peuvent manquer localement, provoquant un échec qui n'aurait pas eu lieu en conditions réelles.
- Les actions qui dépendent explicitement du contexte GitHub (créer un commentaire sur une pull request, publier un artefact) nécessitent une configuration ou un jeton d'accès spécifique pour fonctionner en local, quand elles fonctionnent tout simplement en conditions réelles.
- Les workflows utilisant des runners auto-hébergés spécifiques à l'infrastructure de l'agence ne peuvent pas être reproduits fidèlement par act, qui se limite aux runners standards.

## Où act change vraiment la donne

Sur la mise au point d'un nouveau pipeline de A à Z (par exemple un nouveau job de déploiement ajouté à un workflow existant), act permet de tester chaque itération en quelques secondes plutôt qu'en attendant le retour du serveur distant à chaque tentative. Pour une modification mineure sur un pipeline déjà stable et éprouvé, l'écart de fidélité entre act et l'environnement réel devient moins critique, et un simple test sur une branche dédiée reste parfois plus rapide à valider.

> act ne dispense jamais d'un dernier test réel sur GitHub avant de considérer un pipeline comme validé : c'est un outil d'itération rapide, pas un substitut complet à l'environnement de production CI.

## En résumé

Pour une équipe qui modifie régulièrement ses workflows GitHub Actions, act réduit fortement le temps perdu à attendre un retour distant sur chaque essai, en particulier lors de la construction d'un nouveau pipeline complexe. Il ne remplace pas totalement un test final en conditions réelles, mais il absorbe l'essentiel des itérations de mise au point, sans consommer une seule minute CI facturée.