Accélérer les tests Go parallèles en remplaçant actions/setup-go
En bref
- CloudX a développé une alternative à actions/setup-go qui réduit les temps de test Go de 69% en exploitant mieux le cache de compilation.
- Le problème principal : la clé de cache par défaut de l'action officielle ne change que si le fichier go.mod est modifié, ce qui laisse des caches obsolètes s'accumuler et les jobs parallèles se concurrencent pour écrire leur état.
- La nouvelle action cloudx-io/setup-go utilise une stratégie de cache plus granulaire et nettoie le cache accumulé, d'où le gain observable.
Ce que dit la source
CloudX affirme que l'action officielle GitHub actions/setup-go crée un goulot d'étranglement dans les workflows CI parallèles. La clé de cache utilisée par défaut, basée uniquement sur le système d'exploitation, l'architecture, la version de Go et le hash de go.mod, ne change que rarement, ce qui signifie que les exécutions ultérieures du CI restaurent un cache figé à partir du premier run. Pendant ce temps, les jobs parallèles (linting, testing, build) se disputent l'accès en écriture à ce même cache, ce qui introduit des incohérences. L'entreprise estime que 86% du travail effectué par l'action par défaut est inutile dans leur configuration.
- La clé de cache standard `setup-go-${os}-${arch}-go-${goVersion}-${hashFiles('**/go.mod')}` reste identique pour chaque modification du code tant que go.mod n'est pas touché, ce qui signifie que les sorties de build et de test deviennent progressivement obsolètes
- Les jobs parallèles (lint, test, build exécutés en même temps) se font concurrence pour persister leur état local distinct dans le cache GitHub, chacun ayant exécuté des commandes différentes, si le lint termine en premier, il sauvegarde un cache sans l'état des tests frais
- Go dispose de trois caches filesystem distincts : le cache des modules (GOMODCACHE), et les caches de build et test (GOCACHE) qui stockent les outputs de ces opérations s'ils ne changent pas
- L'accumulation du cache pose un problème caché : au fur et à mesure que le cache grandit, le temps de restauration depuis le service cache GitHub augmente aussi, devenant un facteur significatif du temps total de CI
- La solution propose une clé de cache plus granulaire et ajoute un nettoyage régulier du cache via un algorithme mark-and-sweep pour éviter que le cache ne devienne trop volumineux
- Go 1.24 introduit GOCACHEPROG, un système pluggable qui pourrait théoriquement permettre du remote caching ou des outils de mesure custom du cache
- L'auteur signale que l'action cloudx-io/setup-go reste brève mais admet que les détails techniques sont dans le code et le blog post
Dans les commentaires
Débat pragmatique et bienveillant, sans scepticisme majeur. Deux commentateurs pointent des approches alternatives existantes (vbernat avec actions/cache direct + refresh quotidien, y0ssar1an demandant la comparaison avec setup-go-faster), un demande un patch upstream, un autre souligne simplement que les 69% de gains expliquent pourquoi c'était une friction. Peu de contestation du diagnostic.
- Un commentateur propose une stratégie minimaliste alternative : désactiver le cache dans setup-go et construire soi-même actions/cache avec une clé qui change quotidiennement, ce qui évite l'accumulation de cache obsolète tout en restant simple
- L'existence d'au moins une autre action concurrent, setup-go-faster (WillAbides), est mentionnée sans que le fil n'élabore sur les différences ou avantages respectifs
- Un commentateur suggère que le vrai gain passe par une infrastructure personnalisée (images Docker précalculées) plutôt que par des actions publiques, bien que sans contester le résultat de CloudX
Alternatives citées : setup-go-faster (WillAbides), actions/cache direct avec refresh quotidien via une clé variant chaque jour
Notre lecture
L'amélioration est réelle et reproductible : un gain mesurable de 69% sur les runtimes CI parallèles GO repose sur une compréhension fine du cache Go et des limites de l'action GitHub. L'angle technico-infrastructure est solide ; l'auteur est présent sur le fil et reconnaît humblement que c'est une amélioration « petite » qui s'est révélée très utile en pratique. Pour une équipe Go avec des jobs CI parallèles, tester cette alternative ou au moins examiner la stratégie de cache qu'elle propose est justifié. Les limites : le contexte spécifique (monorepo CloudX, 3 jobs parallèles) rend difficile la transposition mécanique à tous les projets. L'existence d'alternatives existantes (setup-go-faster, actions/cache custom) suggère que le problème est connu, pas révolutionnaire, mais cette solution est clairement documentée et dispo.