Skip to content

Renovate : qui propose les mises à jour, et pourquoi il s'est tu deux semaines

Renovate ouvre les MR de mise à jour de ce projet. Il ne tourne pas ici : il vit dans un projet à part, yk-devops/renovate-runner. Cette page dit comment les deux se parlent, comment ajouter un dépôt, et comment lire une panne.

En trois phrases

Du 29/09 au 12/10/2026, Renovate n'a proposé aucune mise à jour : son jeton GitLab avait expiré, et rien ne l'a signalé. Le jeton est renouvelé depuis le 12/10, et le passage suivant a ouvert quatre MR. Depuis #248, un job du lundi prévient 30 jours avant l'expiration des jetons qu'il peut lire. Il reste un second jeton refusé, celui de GitHub.

Les mots du sujet

Terme Ce que c'est
Renovate Un robot qui compare les versions utilisées dans un dépôt aux versions publiées, et ouvre une MR quand l'une est en retard.
SCA Software Composition Analysis, l'analyse des dépendances d'un logiciel. Renovate en est la partie proactive : mettre à jour avant qu'une CVE ne tombe.
Autodiscover Le mode où Renovate parcourt lui-même tous les dépôts auxquels son compte a accès, au lieu d'une liste tenue à la main.
Onboarding La MR « Configure Renovate » qu'il ouvre sur un dépôt pas encore configuré. Tant qu'elle n'est pas mergée, il ne propose rien d'autre.
Preset Une configuration partagée qu'un dépôt reprend par extends. Ici default.json, dans renovate-runner.
Manager Le module de Renovate qui sait lire un type de fichier : dockerfile, gitlabci, pip-compile, terraform...
Digest L'empreinte sha256 d'une image. Un tag peut changer d'image, un digest non.
PAT Personal Access Token, un mot de passe d'API lié à un compte. Il porte une date d'expiration.

Le mécanisme

Ouvrir le schéma en plein écran

Le chemin, étape par étape :

  1. Le schedule. Chaque lundi à 6 h (0 6 * * 1, Europe/Paris), le schedule 4316912 du projet renovate-runner lance un pipeline d'un seul job, renovate.
  2. Le job. Il tourne sur les runners partagés de GitLab, pas sur le runner auto-hébergé. Le runner éteint ne l'empêche donc pas de partir.
  3. L'authentification. Le job se présente à GitLab avec RENOVATE_TOKEN, le PAT du compte renovatebotyk. C'est le maillon qui a cassé.
  4. La lecture. En autodiscover, il parcourt les dépôts du groupe yk-devops. Sur celui-ci, il lit renovate.json, qui étend le preset commun.
  5. Les MR. Pour chaque version en retard, il crée une branche renovate/... et une MR, avec renovatebotyk comme auteur.
  6. La validation. Chaque MR déclenche son pipeline ici, sur le runner auto-hébergé. Renovate ne décide de rien : c'est la CI qui prouve que la mise à jour ne casse rien.
  7. Le merge. Il est manuel. Aucune MR Renovate ne se merge seule.

Qui règle quoi

Réglage Où Valeur
Dépôts parcourus config.js de renovate-runner autodiscover, filtre yk-devops/**
Rythme, groupage, labels default.json de renovate-runner minor et patch groupés, chaque major isolé
Délai avant d'adopter une version default.json minimumReleaseAge de 3 jours, 0 pour un digest
Fichiers lus dans ce dépôt renovate.json, enabledManagers pip-compile, dockerfile, gitlabci, kustomize, terraform, custom.regex
MR par heure dans ce dépôt renovate.json, prHourlyLimit 10, contre 2 dans le preset (#209)
Les deux fichiers de CI renovate.json, gitlabci .gitlab-ci.yml et .gitlab-ci-infra.yml (#206)

Les deux jetons

Les deux sont des variables masquées et protégées du projet renovate-runner. Aucun n'est dans ce dépôt.

Variable Compte Sert à Si elle est refusée
RENOVATE_TOKEN renovatebotyk sur GitLab, scope api lire les dépôts, créer branches et MR le job échoue, aucune MR
GITHUB_COM_TOKEN un compte GitHub interroger GitHub pour les versions qui y sont publiées un avertissement, le job reste vert

Un jeton sert tous les dépôts

Renovate tourne une fois pour tout le groupe. Un RENOVATE_TOKEN expiré arrête les mises à jour de chaque dépôt suivi, pas seulement de celui-ci.

Ajouter un dépôt à scanner

  1. Donner l'accès. Le compte renovatebotyk doit avoir le rôle Developer sur le dépôt. Un dépôt du groupe yk-devops l'a déjà.
  2. Attendre le lundi, ou lancer le schedule. Renovate ouvre sur ce dépôt une MR « Configure Renovate ».
  3. Merger cette MR. Elle ajoute un renovate.json qui étend le preset. Au passage suivant, Renovate propose les mises à jour.

Avant de merger l'onboarding, restreindre enabledManagers au périmètre voulu évite de recevoir d'un coup toutes les mises à jour de tous les types de fichiers.

Pour lancer un passage sans attendre le lundi :

glab api -X POST 'projects/yk-devops%2Frenovate-runner/pipeline_schedules/4316912/play'

Pourquoi pas un simple pipeline

Le job n'accepte que les sources schedule et web. Un pipeline créé par l'API porte la source api, ne correspond à aucune règle, et GitLab refuse de le créer. Jouer le schedule produit bien la source schedule.

Un dépôt sans fichier que Renovate sait lire reste désactivé, avec le résultat no-package-files. Ce n'est pas une panne.

Lire une panne

Le premier geste est toujours le même : ouvrir le dernier pipeline de renovate-runner, pas celui de ce dépôt.

Symptôme Cause Geste
Aucune MR depuis plus d'une semaine, pipeline renovate rouge en moins de deux minutes RENOVATE_TOKEN expiré : 401 Token is expired dans le log Créer un PAT sur le compte renovatebotyk, remplacer la variable, jouer le schedule
Aucune MR, pipeline renovate vert Rien à mettre à jour, ou la limite horaire atteinte (branch-limit-reached dans le log) Lire le log, il dit pour chaque branche pourquoi elle n'est pas sortie
Pipeline vert, mais github.com token 401 unauthorized dans le log GITHUB_COM_TOKEN refusé Créer un jeton GitHub sans scope, remplacer la variable
La MR existe, son pipeline reste en pending Le runner auto-hébergé est éteint, les jobs portent le tag ubuntu Rallumer le runner, relancer le pipeline à la main (#242)
La MR existe, run-tests échoue sur No space left on device Disque du runner plein Voir #242, le garde-disque nettoie au démarrage et chaque heure

Un repère rapide : l'issue Dependency Dashboard est réécrite à chaque passage réussi. Sa date de mise à jour est la date du dernier passage qui a fonctionné sur ce dépôt.

Ce qui s'est passé

Date Fait
2026-06-30 Renovate passe du mode d'essai au mode actif, il ouvre de vraies MR
2026-09-05 La limite de 2 MR par heure bloque quatre branches : relevée dans ce dépôt (#209). Le fichier .gitlab-ci-infra.yml n'était lu par personne : ajouté (#206)
2026-09-28 Dernier passage vert avant la panne, quatre MR. Trois d'entre elles échouent sur run-tests : disque du runner plein (#242)
entre le 28/09 et le 05/10 Le PAT de renovatebotyk expire. GitLab envoie un mail d'expiration, qui est reçu, mais qui ne dit pas quel projet en dépend
2026-10-05, 2026-10-12 Le job renovate échoue en 401 Token is expired. Aucune MR, aucune alerte
2026-09-28 au 2026-10-12 Des CVE sortent sur PyJWT et urllib3. Renovate étant muet, c'est le scan de 8 h qui les trouve, et le correctif est fait à la main (#243)
2026-10-12 Panne trouvée en cherchant autre chose. Jeton renouvelé, passage 2939399193 vert, quatre MR ouvertes et mergées (!449 à !452)
2026-10-12 Le même log montre GITHUB_COM_TOKEN refusé (Bad credentials), pipeline vert malgré tout. Absent des trois passages précédents

La correction

Fait. Un nouveau PAT pour renovatebotyk, qui expire le 2027-01-31, posé dans RENOVATE_TOKEN.

Rendre le mail lisible. L'avertissement existait déjà : c'est le mail de GitLab. Il n'a pas été suivi parce que rien n'y reliait le jeton à sa conséquence :

  • nommer chaque jeton d'après son usage, par exemple RENOVATE_TOKEN de renovate-runner ;
  • tenir l'inventaire des jetons, avec leur compte, leur variable et leur date ;
  • mettre la date d'expiration dans un agenda.

Le job token-check (#248). Le mail arrive dans la boîte d'un compte robot que personne ne lit, d'où un second signal, sur Slack. Le schedule du lundi à 7 h lance scripts/check-token-expiry.sh sur les runners partagés, le .112 peut donc être éteint. Il alerte si :

Ce qu'il lit Comment
Tous les PAT du compte ykadi, le sien compris GITLAB_READ_TOKEN (read_api) liste les jetons de son compte
GITLAB_PUSH_TOKEN (write-back GitOps) le jeton demande sa propre date, /personal_access_tokens/self. Seul un 401 (jeton mort) alerte, voir ci-dessous
Le dernier passage de Renovate statut du dernier pipeline planifié de renovate-runner

Sa limite : un PAT ne liste que les jetons de son compte. RENOVATE_TOKEN appartient à renovatebotyk et vit dans un autre projet. Le job ne voit donc son expiration qu'à travers l'échec de Renovate, au plus tard le lundi suivant. Le copier ici aurait fait deux copies d'un secret à tourner ensemble. Le jeton GitHub n'est pas couvert du tout : GitLab ne connaît pas sa date.

GITLAB_PUSH_TOKEN a une seconde limite. C'est un PAT fine-grained du compte yk-gitops-bot, réduit au push sur le dépôt. GitLab lui refuse donc la lecture de sa propre date et répond 403 (premier run, 14/10). Le job lit ce 403 comme « jeton vivant, date illisible » et n'alerte pas. Lui donner un droit de lecture d'API pour ce seul contrôle élargirait la clé du write-back, contre l'ADR 032. Sa date (2027-03-31) reste notée dans .gitlab-ci.yml, et un jeton mort répond 401, qui alerte toujours.

Le schedule tourne à 7 h, et pas plus tard, pour une raison précise. Sous la config infra, tout pipeline planifié lance infra-stop. Un schedule qui part pendant un montage détruirait donc le cluster. À 7 h, aucune session n'est ouverte.

Ce que ça ne fait pas

  • Renovate ne valide rien. Une MR verte prouve ce que la CI de la MR teste, pas plus. L'image alpine/ansible ne sert qu'au bootstrap : son digest n'est exercé qu'au montage suivant.
  • Un jeton GitHub refusé laisse le pipeline vert. Les versions publiées sur GitHub ne sont alors plus suivies, sans aucun signal.
  • Tout n'est pas suivi. Les dépendances du frontend n'ont aucun manager (#215), et Helm 4 est bloqué volontairement (#216).
  • La mise à jour de la version d'EKS n'est pas une MR comme les autres. Elle reste en brouillon tant que la compatibilité avec Cilium n'est pas prouvée, voir Version du cluster.

Ce qu'il faut retenir

  • Un outil qui tourne ailleurs se diagnostique ailleurs : la panne était lisible dans le projet renovate-runner, invisible depuis celui-ci.
  • Un silence n'est pas une bonne nouvelle. « Aucune MR cette semaine » veut dire « tout est à jour » ou « le robot est mort », et seul son log tranche.
  • Un avertissement qui ne dit pas ce qu'il va casser n'est pas lu. Le mail d'expiration était arrivé.
  • Le principe et les garde-fous de Renovate sont dans Vuln management.