Aller au contenu

Configurer les montées de version automatiques (Renovate)

Vous êtes mainteneur·se de Kirexo et vous voulez activer Renovate : un bot qui ouvre automatiquement des merge requests pour monter les versions des dépendances (Composer, npm, images Docker, jobs CI) et signaler en priorité les failles de sécurité.

Renovate tourne en self-hosted dans la CI GitLab (job dependencies:renovate, .gitlab/ci/dependencies.yml). Sa configuration vit dans renovate.json à la racine du dépôt. Le job ne se déclenche que sur une pipeline planifiée (schedule) — il faut donc une schedule GitLab et un token.

Prérequis

  • Vous avez les droits Maintainer ou Owner sur le projet GitLab.
  • Les fichiers .gitlab/ci/dependencies.yml et renovate.json sont présents dans le repo (introduits à l'étape 4).
  • La variable CI/CD GITLAB_TOKEN existe déjà (créée pour tag:create / security:composer-audit, cf. Variables CI/CD GitLab). Renovate la réutilise — aucun token séparé à créer.
  • Vous savez créer une schedule GitLab (cf. Configurer l'audit de sécurité quotidien). Une seule schedule quotidienne déclenche tous les jobs de maintenance : security:composer-audit, dependencies:renovate, tools:version-check, container_scanning et security:container-issue.

1. Réutiliser le GITLAB_TOKEN existant

Renovate doit pouvoir créer des branches et des merge requests dans le dépôt. Il n'a pas besoin d'un token dédié : le job dependencies:renovate alimente la variable d'environnement que lit Renovate avec le GITLAB_TOKEN du projet, via le mapping suivant (déjà présent dans .gitlab/ci/dependencies.yml) :

variables:
  RENOVATE_TOKEN: $GITLAB_TOKEN

Il n'y a donc aucune variable CI/CD RENOVATE_TOKEN à déclarer côté GitLab. Tout passe par l'unique GITLAB_TOKEN.

Pourquoi un PAT et pas un project access token

Kirexo est hébergé sur GitLab.com en tier gratuit, où les project access tokens ne sont disponibles qu'en Premium/Ultimate. GITLAB_TOKEN doit donc être un Personal Access Token (PAT) d'un compte ayant le rôle Maintainer (ou plus) sur le projet, avec les scopes api et write_repository — ces deux scopes couvrent à la fois la création d'issues/MRs (api) et la création de branches et de tags (write_repository). Le détail de création du token est documenté dans Variables CI/CD GitLab.

2. S'appuyer sur la schedule existante

Le job dependencies:renovate se déclenche sur $CI_PIPELINE_SOURCE == "schedule", exactement comme security:composer-audit. Si vous avez déjà créé la schedule décrite dans Configurer l'audit de sécurité quotidien, vous n'avez rien de plus à faire : la prochaine exécution planifiée lancera aussi Renovate.

Si la schedule n'existe pas encore, créez-la (une seule suffit pour tous les jobs scheduled) :

Champ Valeur
Description Maintenance quotidienne
Interval pattern 0 5 * * * (5 h UTC)
Target branch main
Activated Coché

3. Déclencher immédiatement pour tester

Depuis Build → Pipeline schedules, cliquer sur l'icône ▶ à droite de la schedule. La pipeline se lance avec $CI_PIPELINE_SOURCE == "schedule" et joue dependencies:renovate. Au premier passage, Renovate ouvre en général :

  • une issue Dependency Dashboard récapitulant toutes les mises à jour détectées ;
  • une ou plusieurs merge requests selon ce qui est en retard.

Ce que fait Renovate (config renovate.json)

La configuration à la racine définit ce comportement :

Réglage Effet
extends: config:recommended, :dependencyDashboard Base recommandée + issue de tableau de bord.
labels: ["dependencies"] Toutes les MRs portent le label dependencies.
prConcurrentLimit: 5 Maximum 5 MRs Renovate ouvertes en même temps (limite le bruit).
osvVulnerabilityAlerts: true Active la détection des vulnérabilités via OSV.dev (multi-écosystèmes : npm, Composer, etc.). Indispensable sur GitLab : sans cette option, Renovate n'a aucune source d'advisories npm (l'API GitHub Advisory que Renovate utilise par défaut côté GitHub n'a pas d'équivalent côté GitLab). Limite à connaître — voir la section ci-dessous : OSV ne couvre que les dépendances directement déclarées, pas les transitives.
vulnerabilityAlerts Activé — configure les MRs de sécurité produites par la détection ci-dessus : labels (security, dependencies), prPriority: 10 (passe en tête), prConcurrentLimit: 0 (pas de plafond), création immédiate sans fenêtre horaire (schedule: [] explicite — une CVE n'attend pas le créneau suivant).
lockFileMaintenance Renovate rafraîchit périodiquement composer.lock / yarn.lock même sans changement de version déclaré. Le module porte son propre schedule:weekly intégré (préconfiguré par Renovate, indépendant de l'extends) — c'est le seul endroit où une fenêtre hebdomadaire reste appliquée.
Règle « dépendances non majeures » Les mises à jour mineures et patch sont regroupées dans une seule MR (groupName: dépendances non majeures).
Règle « majeures isolées » Chaque mise à jour majeure a sa propre MR (groupName: null) pour une review manuelle.

Renovate couvre Composer, npm, les images Docker et les versions des jobs CI (manager gitlabci). Il suit même son propre tag renovate/renovate:43 et proposera son propre bump.

Renovate s'exécute à chaque cron quotidien — pas une fois par semaine

L'extends de renovate.json ne contient plus schedule:weekly. La cadence réelle de Renovate est désormais pilotée par la schedule GitLab 0 5 * * *, qui lance dependencies:renovate chaque matin en même temps que les autres jobs de maintenance. Avant ce changement, schedule:weekly n'autorisait Renovate à ouvrir/mettre à jour ses MRs que sur une fenêtre lundi tôt matin : le cron CI tournait donc 6 jours sur 7 pour rien (Renovate démarrait, voyait qu'il était hors créneau, et sortait sans rien faire). En supprimant schedule:weekly, Renovate utilise sa cadence par défaut « à chaque exécution » — et c'est la schedule CI qui définit la cadence réelle.

Seules les MRs de sécurité (vulnerabilityAlerts.schedule: []) et le lockFileMaintenance (schedule:weekly natif, configuré au sein du module Renovate) gardent un comportement de fenêtre. Les premières n'attendent jamais (CVE = traitée tout de suite) ; le second reste hebdo pour ne pas générer une MR de refresh de lock chaque jour.

Limite — OSV ne voit que les dépendances directes

osvVulnerabilityAlerts interroge OSV.dev sur les paquets directement déclarés dans composer.json / package.json. Les dépendances transitives vulnérables ne déclenchent pas de MR de sécurité Renovate — leur correction passe par un bump du parent direct (ou par lockFileMaintenance quand la nouvelle résolution de lock ramène la version patchée).

Le filet de sécurité complémentaire pour les transitives est porté par les jobs quality:composer-audit (bloquant sur chaque MR / main / tag) et security:composer-audit (cron quotidien, ouvre une MR de patch ou une issue) — ils auditent composer.lock dans son ensemble, transitives comprises. Voir Pipeline GitLab CI — Job quality:composer-audit.

Ce que Renovate ne voit pas

Les versions épinglées par directive ARG dans le Dockerfile (Node, Claude Code) ne sont pas détectées nativement par Renovate. Elles sont surveillées par le job tools:version-check, qui ouvre une issue plutôt qu'une MR.

Cas d'erreur

Le job échoue avec une erreur d'authentification

GITLAB_TOKEN est absent, expiré, ou n'a pas les scopes api + write_repository (Renovate le lit via le mapping RENOVATE_TOKEN: $GITLAB_TOKEN). Régénérer le PAT (Settings → Access Tokens, sur le compte propriétaire) et mettre à jour la variable CI/CD GITLAB_TOKEN.

Renovate scanne d'autres projets que Kirexo

Ne devrait pas arriver : le job fixe RENOVATE_AUTODISCOVER: "false" et RENOVATE_REPOSITORIES: $CI_PROJECT_PATH, ce qui cible explicitement ce dépôt. Si vous observez le contraire, vérifier que ces variables n'ont pas été surchargées.

Le job ne se déclenche jamais

Le job ne tourne que sur $CI_PIPELINE_SOURCE == "schedule". Vérifier qu'une schedule activée existe (cf. Configurer l'audit de sécurité quotidien — La schedule ne se déclenche jamais).

Voir aussi