Scylla

Le problème

GitHub Actions est la réponse par défaut pour la CI, et c’est souvent la bonne. Mais dès qu’un job doit atteindre une base interne, tourner sur une machine précise (celle avec le GPU, celle qui a le cache chaud) ou rester dans un périmètre réseau qu’on maîtrise, le modèle « tout chez un tiers » montre ses limites.

Scylla garde toute la boucle chez soi : le plan de contrôle, les workers, les logs et les secrets.

Comment c’est construit

• Un plan de contrôle en Rust : API gRPC, ordonnancement et dispatch des jobs, sans broker de messages intermédiaire.
• Un agent par machine, qui reçoit les jobs et remonte leurs résultats.
• PostgreSQL comme source de vérité : pipelines, exécutions, organisations, droits.
• Des pipelines décrits comme des graphes (nœuds et dépendances) plutôt que comme une liste linéaire d’étapes.
• Des déclencheurs webhook signés, compatibles avec les signatures GitHub.

Ma part

Je suis core maintainer, surtout côté interface et expérience utilisateur, et je passe une bonne partie de mon temps à diagnostiquer les bugs qui traversent toute la pile.

• Migration de l’interface vers Svelte et TypeScript, terminée en septembre 2026.
• Un tour d’onboarding en 21 étapes pour guider les nouveaux venus, livré après quatre tours de relecture, avec une suite de plus de 1 700 tests au vert.
• Visualisation des résultats d’agents (barres empilées par issue d’exécution).
• Dogfooding : je fais tourner une instance Scylla sur mon homelab, qui construit et teste mes propres projets. Les bugs qu’on y trouve remontent dans le tracker du projet.

Ce que j’en retiens

Maintenir un projet open source, c’est autant relire, trier et expliquer que coder. Et utiliser son propre outil tous les jours reste le meilleur moyen de savoir où il fait mal.