Renovate
Renovate est un outil que j’apprécie et utilise beaucoup. J’ai d’ailleurs écrit cet article de blog à son sujet et surtout donné un talk avec Lise Quesnel, que nous avons eu la chance de présenter dans plusieurs conférences (comme au Devoxx France 2025). Cet outil détecte les nouvelles versions de vos dépendances et vous propose de les mettre à jour sous forme de Pull Requests (PR) ou de Merge Requests (MR). Très pratique pour garder ses dépendances à jour et récupérer les éventuels patchs de sécurité automatiquement dès leur sortie.
Hacktoberfest et le regroupement de mes projets
Avant l’Hacktoberfest de cette année (l’événement mondial de l’open source), j’ai voulu rassembler dans un groupe GitLab l’ensemble de mes projets open source. Et bien sûr, la première étape sur laquelle j’ai travaillé consistait à revoir la configuration Renovate pour qu’il s’exécute régulièrement. Pour ma part, j’ai choisi de planifier l’exécution tous les lundis matin.
Ma problématique était de devoir faire une passe sur les Merge Requests chaque début de semaine pour éviter d’accumuler de la dette technique. Ma configuration de Renovate merge automatiquement les MR qui portent sur une version patch ou mineure d’une dépendance, à condition bien sûr que le pipeline de CI/CD passe sans erreur. Pour les majeures, je préfère (pour le moment) garder un œil dessus. Elles ont généralement des impacts non négligeables et demandent de prendre le temps de les traiter.
Les MR sont mergées automatiquement, mais comme je récupère plusieurs MR lors du même passage de Renovate, je me retrouve avec plusieurs MR sur chacun de mes projets. Et dès que l’une d’elles est mergée, les autres ne sont plus à jour par rapport à la branche principale : il faut les rebaser et relancer leur pipeline, ce que Renovate ne fera qu’à sa prochaine exécution. On pourrait aussi regrouper les mises à jour mineures et patch dans une seule MR mais il suffit alors qu’une seule dépendance casse le build pour bloquer toutes les autres.
Première étape : les merge trains
Pour gérer ce flux, la première étape a été d'utiliser les Merge Trains de GitLab. Cette fonctionnalité (disponible sur les projets Ultimate) permet d’empiler les MR pour lesquelles le merge a été activé dans une file d'attente. GitLab se charge ensuite de rebaser automatiquement les branches et de les intégrer une à une sans casser le build.
Les agents à mon secours ?
Je me suis dit qu’il y avait quelque chose à automatiser là-dedans et, à l’ère de l’IA, je me suis demandé si la solution ne serait pas de créer une tâche programmée dans Antigravity pour lui demander de traiter les MR. C’est possible, mais il faudrait qu’Antigravity soit en mode “super user” pour aller merger tout seul les MR de mes projets. Et déléguer ce genre de chose à une IA semble un peu abusif, non ? Vérifier l’état d’un pipeline puis lancer un merge, un simple script le fait très bien, sans consommer de tokens à chaque passage.
J’ai plutôt opté pour une application qui va :
- récupérer les projets que je mentionne dans un fichier de configuration ;
- vérifier, à l’aide de glab (la CLI de GitLab), l’état des MR de chaque projet ;
- activer, toujours via glab, l’auto-merge sur les MR dont les pipelines sont OK.
Et Antigravity dans tout ça ?
Quand un pipeline échoue, c’est là qu’Antigravity intervient. J’ai développé une application qui lance une commande avec la CLI Antigravity, récupère la branche sur mon ordinateur, lit l’erreur de la CI et essaie de la résoudre. Je lui fais confiance pour pousser un correctif sur la branche et, si le pipeline passe, pour merger la MR. La différence avec mon idée de départ : l’agent n’intervient que lorsqu’un pipeline échoue, là où une IA a quelque chose à apporter. Tout le reste est géré par du code classique, prévisible.
Cette application est écrite en Go, langage que j’avais déjà utilisé. Le SDK d’Antigravity n’est pas encore disponible dans ce langage, mais la CLI Antigravity répond très bien à mon besoin.
Pour que ce soit agréable à utiliser, j’ai doté l’application d’une interface graphique Mac qui permet de visualiser les travaux en cours et d’accepter ou de refuser les tâches pour lesquelles les agents Antigravity ont besoin de mon approbation. Pour le côté “fun” et pour l’avoir vu sur d’autres applications, j’ai voulu représenter graphiquement ces agents par un personnage ou un robot, avec une apparence différente selon son état :
- au repos ;
- en activité ;
- en surmenage ;
- ou en attente de validation de ma part.
L’application me permet donc de traiter les mises à jour de mes projets open source super rapidement, tout en gardant le contrôle sur ce qui se passe. L’application tourne en permanence sur ma machine, se réveille dès que je déverrouille ma session et garde un œil sur les MR Renovate de mes projets open source 🙌 .
Prérequis techniques
Pour exécuter l’application, il faut avoir :
MacOS
glab, la CLI de GitLab, installée et authentifiée sur son compte GitLab ;
la CLI Antigravity, installée et connectée à son compte.
Mon nouvel outil open source 🙌
Dans cette application, chaque outil a son rôle :
- Renovate détecte les mises à jour,
- les merge trains de GitLab les intègrent proprement,
- un peu de Go orchestre le tout,
- Antigravity n’intervient que lorsqu’un correctif demande de comprendre l’erreur.
La prochaine étape de cette application consistera à ajouter l’intégration GitHub et dependabot, afin de traiter également mes projets disponibles sur cette plateforme.
👉 Le projet est disponible sur GitLab : https://gitlab.com/jeanphi-baconnais-oss/oss-helper.
Top comments (0)