Je déteste vraiment GitHub Actions

• Partage de l’expérience frustrante d’un développeur face à la boucle de feedback lente et au débogage complexe de GitHub Actions
• Dans le projet tmplr, la documentation était générée avec CUE via build.rs, mais les échecs du build CI ont déclenché le problème
• Sur 4 plateformes, seul Linux ARM échouait au build ; la cause était le comportement de GitHub Actions qui masque les binaires x86_64 sur un runner arm64 lors d’un cross build
• Une boucle de feedback inefficace où 2 à 3 minutes étaient nécessaires pour tester une seule modification
• Solution adoptée : suppression de build.rs et passage à un GNU Makefile, afin de contrôler directement la logique CI et de résoudre le problème

---

Contexte du problème

• tmplr est un outil de scaffolding de fichiers/projets qui utilise des fichiers de template lisibles et modifiables par des humains
• build.rs utilisait CUE pour générer README.md, CHANGELOG.md ainsi que les fichiers de version et d’aide, afin de garantir la cohérence
• Le travail en lui-même a été terminé en environ 1,5 heure, et l’article associé était également déjà rédigé
• Tout fonctionnait en local, mais dans l’environnement CI de GitHub Actions, le build a échoué parce que le binaire CUE n’était pas installé

Cause de l’échec du build

• Parmi 4 plateformes (Linux ARM, macOS ARM, Linux x86_64, macOS x86_64), seul Linux ARM produisait une erreur « command not found »
• Cause : le matrix cross build est fortement isolé, si bien que CUE n’était installé que sur l’hôte Linux x86_64 et l’hôte macOS ARM
  • Sur macOS, exécuter un binaire x86_64 ne pose pas de problème
  • Sur Linux x86_64 non plus, exécuter un binaire x86_64 ne pose pas de problème
  • En revanche, GitHub Actions masque les binaires x86_64 sur un runner arm64, les rendant impossibles à exécuter

Une boucle de feedback inefficace

• Processus répété pour tenter de résoudre le problème :
  1. chercher des corrections possibles
  2. modifier ci.yml
  3. commit et push (jj squash --ignore-immutable && jj git push)
  4. ouvrir l’onglet « Actions »
  5. ouvrir la dernière exécution
  6. ouvrir l’exécution Linux ARM
  7. attendre quelques secondes
  8. frustration
  9. recommencer
• 2 à 3 minutes étaient nécessaires par modification
• Dans l’idéal, GitHub fournirait soit un runner local complet, soit une fonction permettant de vérifier rapidement la progression après un push
  • Une fonctionnalité du type « scratch commit » : un moyen de tester différentes exécutions sans polluer l’historique Git ni l’historique des exécutions Actions
• Mais à ce jour, une telle fonction n’existe pas

Solution

• Après avoir répété cette boucle pendant 30 minutes, arrêt
• Application d’une méthode bien connue sur Internet : « ne laissez pas GitHub Actions gérer la logique ; contrôlez directement le script et laissez Actions se contenter de l’appeler »
• Suppression de build.rs (à regret, mais le sacrifice était nécessaire)
• Déplacement de toutes les tâches de génération dans un GNU Makefile
• Commit des fichiers générés dans le dépôt et annulation des changements CI
• Problème résolu

Conclusion

• GitHub Actions empêche parfois de bénéficier de certaines bonnes approches
• Beaucoup de temps est perdu à déboguer les runners ou à optimiser le processus de build
• Mais il offre aussi des avantages difficiles à obtenir autrement, comme les builds macOS
• Et bien sûr, il n’existe pas vraiment de système réputé plus simple à configurer que GitHub Actions
  > We are all doomed to GitHub Actions. …but at least I dodged the bullet early.