Mises à jour de version

Mises à jour de version est la voie Renovate hébergé des Mises à jour des dépendances. Activez-la pour une organisation, et fremforge ouvre des PR regroupées et faciles à relire selon le calendrier défini par votre renovate.json : npm, gomod, providers Terraform, images de base Dockerfile, charts Helm et tout épinglage par regex personnalisée. Les dépôts de chaque organisation inscrite sont traités chaque nuit ; voir Cadence.

Les dépendances vulnérables trouvées par vos analyses relèvent de l’autre voie : les Correctifs de sécurité ouvrent une pull request par paquet vulnérable. Tant que la voie Correctifs de sécurité n’a pas pris le relais pour votre organisation, Renovate hébergé ouvre aussi ses propres pull requests de sécurité pour les alertes OSV, comme décrit ci-dessous.

Inclus dans l’offre à 30 € par utilisateur. Pas de niveau complémentaire, pas de minutes d’actions tierces, et GitHub (l’entreprise) n’est pas dans le chemin des données.

Ce que vous obtenez

Des PR automatiques pour les dépendances obsolètes, regroupées de façon pertinente : une PR par ensemble de paquets liés plutôt que des dizaines de montées de version d’une ligne.
Des PR déclenchées par les vulnérabilités pour les alertes de sécurité publiées (OSV), ouvertes par l’exécution suivante plutôt que d’attendre votre calendrier, et non retenues par l’attente d’âge de version décrite sous Politique de la plateforme (pour npm, voir l’unique exception qui y figure). Dès que la voie Correctifs de sécurité prend le relais pour une organisation, elles y sont désactivées, de sorte qu’un correctif n’est jamais proposé qu’une fois.
Un ticket Renovate Dependency Dashboard dans chaque dépôt, pour voir l’état d’un coup d’œil.
Le schéma de configuration Renovate complet : chaque option de docs.renovatebot.com fonctionne telle quelle sur fremforge. Vos règles sont appliquées par-dessus la politique de la plateforme.
Un utilisateur bot par tenant, <org>-fremforge-bot-deps, limité à votre seule organisation ; son jeton ne franchit jamais les frontières entre tenants. Les correctifs de sécurité utilisent le même bot.
Souverain dans l’UE : il s’exécute sur T Cloud Public CCE, sans SaaS tiers dans le chemin des données.

Activation

Ouvrez Sécurité › Corriger › Mises à jour des dépendances (ou Build et déploiement › Mises à jour des dépendances) et allez dans Mises à jour de version.
Activez Renovate hébergé.
fremforge provisionne un utilisateur bot par tenant, <org>-fremforge-bot-deps, et lui accorde un accès en écriture aux dépôts de votre organisation.
Les dépôts sont pris en compte par l’exécution nocturne suivante, ou immédiatement avec Exécuter maintenant ; les pull requests suivent ensuite le calendrier de votre renovate.json.

L’activation donne aussi à l’organisation les paramètres par défaut des Correctifs de sécurité : pull requests de correctif sur clic, en attente de relecture.

L’utilisateur bot est géré par fremforge. Vous n’avez pas à le créer, à faire la rotation de ses identifiants, ni à vous soucier de mots de passe perdus. Le jeton est géré par la plateforme et sa rotation est automatique.

Désactivation

Sécurité › Corriger › Mises à jour des dépendances → Mises à jour de version → désactivez Renovate hébergé.
fremforge révoque immédiatement le jeton du bot et retire le bot de votre organisation, sauf si les Correctifs de sécurité sont réglés sur un mode automatique : le bot reste alors, pour les seuls correctifs de sécurité.
Les PR déjà ouvertes par Renovate restent ouvertes. Fusionnez-les ou fermez-les comme n’importe quelle autre PR.
Le renovate.json de l’organisation reste dans vos dépôts ; fremforge n’y touche pas.

Une réactivation provisionne un nouveau bot. L’ancien nom d’utilisateur du bot est conservé comme pierre tombale (il n’est pas réutilisé), afin que l’historique d’audit reste propre.

Politique de la plateforme

Chaque exécution part de la politique de fremforge, et votre renovate.json est appliqué par-dessus.

Cadence. Les dépôts de chaque organisation inscrite sont mis en file pour une exécution chaque nuit (à partir de 02:30 UTC) ; un dépôt traité au cours des 4 dernières heures est ignoré. Un schedule dans votre renovate.json limite toujours le moment où les pull requests courantes sont ouvertes. Les mises à jour de sécurité (alertes de vulnérabilité) ignorent ce calendrier et l’attente d’âge de version, et sont ouvertes par l’exécution qui suit la publication de l’alerte. Exécuter maintenant lance une exécution hors cycle.
Attente d’âge de version. Une mise à jour courante n’est proposée qu’une fois la nouvelle version aussi ancienne que l’âge de version de votre organisation (3 jours, sauf si un propriétaire l’a modifié), de sorte qu’une version malveillante ou défectueuse retirée en quelques jours ne vous atteint jamais. Les registres qui ne publient pas de date de publication n’ont pas d’attente. Les mises à jour de sécurité ignorent l’attente, avec une exception pour npm : une version corrective plus récente que l’âge de version n’est proposée que si les données d’alerte de npm la listent comme corrigeant la version que vous avez. Un correctif que ces données ne listent pas attend comme une mise à jour courante.
L’attente couvre aussi votre fichier de verrouillage. Renovate propose une version, puis votre gestionnaire de paquets résout le fichier de verrouillage, y compris toute nouvelle dépendance transitive. Pour npm, pnpm et Yarn 1, cette résolution passe par la vue du registre npm filtrée par âge de version de fremforge, de sorte qu’une montée de plage ne peut pas verrouiller une version de moins de 3 jours. La vue conserve 3 jours pour chaque organisation ; avec un âge de version plus long, la vérification ci-dessous retient la pull request jusqu’à ce que le fichier de verrouillage soit assez ancien. Votre propre .npmrc est toujours appliqué après elle, de sorte que vos scopes privés et toute ligne registry= de votre part priment. Yarn 2+ lit .yarnrc.yml à la place et n’est pas couvert par la vue ; la vérification ci-dessous retient tout de même ces PR.
Vérification fremforge/release-age. Chaque pull request reçoit cette vérification, et c’est une vérification requise de la protection de branche. Sur une PR de mise à jour de dépendances, elle reste en attente, avec le texte « Waiting until … », jusqu’à ce que chaque version résolue par le fichier de verrouillage soit aussi ancienne que votre âge de version. Elle passe ensuite au vert d’elle-même en quelques minutes, sans nouveau push, et la fusion automatique l’attend. Une version qu’une alerte relue (de toute gravité) sur votre branche de base désigne comme son correctif attend 24 heures à la place, de même qu’une nouvelle dépendance que seul ce correctif a apportée depuis les mêmes éditeurs (la voie des correctifs de sécurité). Un correctif pour une vulnérabilité connue comme exploitée n’est pas retenu. Sur une PR ouverte par une personne, les versions récentes sont signalées mais ne retiennent pas la PR. Régler l’analyseur sur off pour une organisation ou un dépôt retire la vérification de la protection de branche dans l’heure.
Fusion automatique. Les mises à jour de type patch, pin et digest fusionnent automatiquement lorsque la CI est verte, par défaut. Les mises à jour mineures fusionnent automatiquement si vous l’activez dans les paramètres de la politique. Les mises à jour majeures attendent toujours votre approbation sur le Dependency Dashboard.
Paquets à fort rayon d’impact. Une trentaine de paquets d’authentification, de cryptographie, de base de données, d’ORM et de KMS cloud (par exemple jsonwebtoken, jose, bcrypt, pg, redis, drizzle-orm, Prisma) ne fusionnent jamais automatiquement une mise à jour courante ; la PR attend une relecture. Les bibliothèques OpenID peuvent fusionner automatiquement un patch, mais jamais une mineure ni une majeure.
Mises à jour de sécurité. La fusion automatique, CI verte, des PR de sécurité propres à Renovate hébergé dépend du paramètre Quand les correctifs sont fusionnés des Correctifs de sécurité : Fusionner quand les vérifications passent ou Attendre la revue (la valeur par défaut). Les organisations qui avaient activé l’ancienne fusion automatique Security updates, activée par défaut pour toute organisation inscrite, sont passées à Fusionner quand les vérifications passent, si bien que rien n’a changé pour elles. Avec ce réglage, une PR de sécurité fusionne automatiquement pour tous les paquets, y compris ceux à fort rayon d’impact : ce sont justement les bibliothèques que vous voulez voir corrigées au plus vite. Voir Fusion.
Fenêtre de fusion. Un administrateur d’organisation peut limiter les moments où les PR Renovate sont armées pour la fusion, en heures UTC entières sur les jours de semaine choisis (merge_window dans PUT /_app/api/v1/orgs/{org}/dependency-updates/version-updates/settings). En dehors de la fenêtre, aucune PR Renovate n’est armée, et les armements faits par le bot sont annulés à la fermeture de la fenêtre ; un armement fait par une personne est laissé tel quel. Un dépôt ayant un ticket ouvert étiqueté release-freeze n’est jamais armé.
Correctifs de vulnérabilités connues comme exploitées. Une mise à jour de sécurité pour une CVE exploitée dans la nature (listée par l’EU Vulnerability Database de l’ENISA ou le catalogue Known Exploited Vulnerabilities de la CISA, vérifiés chaque jour) est ouverte avant toutes les autres mises à jour de l’exécution, n’est pas retenue par les limites de PR, et porte l’étiquette known-exploited (lorsque votre dépôt possède cette étiquette) ainsi qu’une note dans la description de la PR. Elle est aussi armée en dehors de la fenêtre de fusion, de sorte qu’elle fusionne dès que ses vérifications passent. Seule la fenêtre est ignorée : une PR n’est armée en dehors de la fenêtre que si elle l’aurait été à l’intérieur, et le gel des versions, une personne qui annule la fusion automatique et vos vérifications requises s’appliquent toujours.
Vos règles l’emportent. Les règles de votre renovate.json sont appliquées après cette politique ; une règle automerge: true y prend donc le dessus, y compris sur la retenue pour relecture des paquets à fort rayon d’impact. Si vous ajoutez une telle règle, excluez-en ces paquets (voir l’exemple ci-dessous).

Paramètres

Un propriétaire définit la politique de la voie sur la page, ou avec PUT /_app/api/v1/orgs/{org}/dependency-updates/version-updates/settings (portée dependency-updates:write). Chaque champ est facultatif ; un champ omis conserve sa valeur, et un champ inconnu est refusé avec unknown-field.

Paramètre	Champ d’API	Valeur par défaut
Exécutions de Renovate hébergé	`enabled`	`true`
Fusion automatique des mises à jour patch, pin et digest	`automerge_patch`	`true`
Fusion automatique des mises à jour mineures	`automerge_minor`	`false`
Les mises à jour majeures nécessitent une approbation sur le Dependency Dashboard	`major_approval`	`true`
Calendrier personnalisé (texte de calendrier Renovate)	`schedule`	aucun
Pull requests par heure	`pr_hourly_limit`	2
Pull requests ouvertes simultanément	`pr_concurrent_limit`	5
Fenêtre de fusion	`merge_window`	aucune

GET sur le même chemin renvoie les mêmes champs, avec la même graphie snake_case. security_automerge n’est pas un champ ici : la fusion automatique des PR de sécurité relève du paramètre merge des Correctifs de sécurité, et l’envoi de security_automerge à ce chemin est refusé avec un message qui le précise.

Configuration

La configuration par dépôt se fait via renovate.json à la racine du dépôt. Sans ce fichier, Renovate utilise des valeurs par défaut raisonnables, ce qui convient généralement pour le premier mois, le temps de voir quels types de PR arrivent.

Un point de départ minimal :

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended", ":dependencyDashboard"],
  "schedule": ["before 4am on the first day of the month"]
}

Une configuration plus affirmée, qui regroupe les paquets OpenTelemetry, fusionne automatiquement les montées de patch et de fichier de verrouillage, et exige une relecture humaine pour les montées majeures :

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:recommended", ":dependencyDashboard", ":semanticCommits"],
  "timezone": "Europe/Copenhagen",
  "schedule": ["before 4am on the first day of the month"],
  "vulnerabilityAlerts": {
    "labels": ["security"],
    "schedule": ["at any time"]
  },
  "packageRules": [
    {
      "matchPackagePatterns": ["^@opentelemetry/"],
      "groupName": "opentelemetry"
    },
    {
      "matchUpdateTypes": ["patch", "pin", "digest", "lockFileMaintenance"],
      "automerge": true,
      "platformAutomerge": true
    },
    {
      "matchUpdateTypes": ["major"],
      "automerge": false,
      "labels": ["major-bump"]
    }
  ]
}

La règle automerge de cet exemple est appliquée après la politique de la plateforme ; elle fusionnerait donc aussi automatiquement les paquets d’authentification, de cryptographie et de base de données que fremforge retient sinon pour relecture. Pour les garder manuels, excluez-les de la règle, par exemple "matchPackageNames": ["*", "!pg", "!jose", "!bcrypt"].

La référence complète de la configuration Renovate se trouve sur docs.renovatebot.com/configuration-options/.

Ce qui est mis à jour

Renovate détecte automatiquement la plupart des écosystèmes sans configuration. Écosystèmes détectés automatiquement sur fremforge :

npm / pnpm / yarn : package.json + maintenance du fichier de verrouillage
Modules Go : go.mod
OpenTofu / Terraform : versions des providers dans versions.tf
Dockerfile : lignes FROM, avec option d’épinglage par digest
Helm : versions des charts dans values.yaml et Chart.yaml
Épinglages par regex personnalisée : pour toute chaîne de version dans n’importe quel fichier (idéal pour épingler des binaires installés par des scripts shell)
Python : pyproject.toml, requirements*.txt, Pipfile et Poetry. Les requirements épinglés par empreinte et compilés avec uv pip compile ou pip-compile sont reverrouillés en bloc ; voir Requirements Python compilés.

Pour la matrice complète des écosystèmes, voir docs.renovatebot.com/modules/manager/.

Requirements Python compilés

Un requirements*.txt écrit par uv pip compile ou pip-compile épingle chaque paquet, souvent avec des lignes --hash. Certaines montées de version exigent aussi le déplacement d’un autre épinglage. Par exemple, pydantic épingle pydantic-core à une version exacte. Lorsque l’en-tête du verrouillage nomme la commande qui l’a écrit, Renovate hébergé réexécute cette commande avec --upgrade-package, de sorte que la pull request de mise à jour contient l’intégralité du fichier reverrouillé : le paquet mis à jour, chaque épinglage qu’il déplace, et leurs empreintes. Sans ce reverrouillage, la PR modifie une seule ligne et pip install --require-hashes la refuse.

Renovate hébergé le fait pour tout requirements*.txt dont l’en-tête contient une commande de compilation, dans chaque organisation. Vous n’avez rien à configurer, du moment que l’en-tête respecte les règles de Renovate :

Utilisez les noms d’option longs, et joignez chaque valeur avec =, par exemple --output-file=requirements.txt, --python-version=3.11, --extra=dev et --group=dev. uv écrit la commande dans l’en-tête exactement telle que vous l’avez tapée. Renovate refuse -o requirements.txt et --python-version 3.11, et laisse alors ce verrouillage tel quel.
Nommez le fichier source, par exemple uv pip compile pyproject.toml .... Un en-tête sans fichier source (par exemple uv pip compile --group render ...) n’est pas reverrouillé.
Donnez une contrainte de version à chaque dépendance directe. Une dépendance écrite sans aucune version ("httpx") n’est pas reverrouillée ; sa montée de version ne modifie que sa propre ligne. Un plancher tel que "httpx>=0.28" suffit.

Un en-tête qui fonctionne :

# This file was autogenerated by uv via the following command:
#    uv pip compile pyproject.toml --extra=dev --universal --python-version=3.11 --generate-hashes --output-file=requirements-dev.txt

Renovate conserve --python-version lorsqu’il reverrouille ; réglez-le donc sur la plus ancienne version de Python que vous prenez en charge. Le fichier reverrouillé est le même que celui que produirait votre propre compilation, et il n’enregistre aucune URL d’index.

Le reverrouillage se résout sur PyPI public, le même index que Renovate utilise pour trouver la nouvelle version, sauf si l’en-tête ou votre pyproject.toml nomme un autre index. Un requirements.txt écrit à la main sans en-tête de compilation est mis à jour ligne par ligne, comme auparavant.

Exécutions hors cycle

Besoin d’une exécution de Renovate avant le prochain cycle planifié (par exemple, vous venez de publier un nouveau renovate.json et voulez voir ce qu’il produit) ?

Sécurité › Corriger › Mises à jour des dépendances → Exécuter maintenant.
Limité à une exécution hors cycle par heure et par organisation.
Les résultats apparaissent sous Activité en quelques minutes.

Les PR déclenchées par des vulnérabilités passent déjà automatiquement hors cycle. Vous n’avez pas besoin de cliquer sur « Exécuter maintenant » lorsqu’une nouvelle CVE paraît ; le planificateur de vulnérabilités propre à Renovate s’en charge.

Personnalisation de la cadence

Le champ schedule de Renovate accepte des expressions de type cron. Quelques modèles courants :

["before 4am on the first day of the month"] : une fois par mois. (Par défaut, fremforge n’a pas de calendrier : une exécution chaque nuit, et des pull requests peuvent s’ouvrir à chaque exécution.)
["before 4am every weekday"] : chaque jour ouvré.
["after 9pm and before 5am"] : uniquement en dehors des heures de bureau.
[] : jamais ; seules les exécutions déclenchées par des vulnérabilités ont lieu.

Le champ vulnerabilityAlerts.schedule prend le dessus pour les PR de sécurité :

{
  "vulnerabilityAlerts": {
    "schedule": ["at any time"]
  }
}

Coût

Inclus dans l’offre à 30 € par utilisateur. Pas de mesure à l’usage, pas de frais par PR, pas de ligne distincte de minutes de runner.

À titre de comparaison : Dependabot de GitHub est gratuit, mais les Dependabot Updates qui s’exécutent sur Actions consomment vos minutes Actions. Renovate hébergé de fremforge s’exécute sur une infrastructure CCE gérée par fremforge (distincte de votre pool de runners de CI, il ne consomme donc jamais de minutes de runner). C’est la différence concrète.

Pourquoi Renovate et non Dependabot

Renovate est l’outil open source que nous utilisons sur nos propres dépôts, avec la même configuration, la même cadence et la même forme de PR, et que nous avons choisi d’exposer comme fonctionnalité hébergée de mises à jour des dépendances. Renovate prend en charge Forgejo nativement depuis la v37 ; son schéma de configuration est plus large que celui de Dependabot ; il gère les épinglages par regex personnalisée, ce que Dependabot ne fait pas. La plupart des équipes qui utilisent les deux préfèrent Renovate.

Vous pouvez aussi héberger vous-même Renovate sur vos propres dépôts fremforge sans vous inscrire à la version hébergée. Déposez simplement un renovate.json et exécutez Renovate vous-même dans votre CI. La version hébergée est la couche de confort ; la configuration Renovate open source que vous écrivez est identique dans les deux cas.

Registres privés

Ajoutez un identifiant de lecture sous Sécurité › Corriger › Mises à jour des dépendances → Mises à jour de version → Registres privés :

Libellé : un nom pour votre propre référence (par exemple « GitHub Packages »).
Type : npm, docker ou git (un hôte git privé pour la recherche de modules et de tags, par exemple une source privée de modules Terraform).
URL de l’hôte / du registre : l’hôte du registre (par exemple npm.pkg.github.com) ou un préfixe d’URL https://. Les hôtes loopback, de métadonnées ou de plages privées sont refusés.
Nom d’utilisateur : uniquement pour l’authentification basique Docker ; laissez vide pour npm et git avec jeton seul.
Jeton / mot de passe : un jeton en lecture seule pour ce registre.

Le jeton est stocké chiffré (AES-256-GCM), utilisé uniquement pour vos propres exécutions de Renovate, jamais renvoyé par l’API et, contrairement à un secret Actions, jamais exposé à vos workflows de CI. Renovate s’authentifie auprès de ce registre à l’exécution suivante. Vous pouvez supprimer un identifiant à tout moment ; les recherches de ses paquets recommenceront alors à échouer jusqu’à ce que vous l’ajoutiez de nouveau.

C’est l’équivalent fremforge des secrets de registre de Dependabot sur GitHub.

Renvois

Documentation de Renovate (en amont) : la référence complète de la configuration.
Sécurité et chaîne d’approvisionnement : la place de Renovate dans l’ensemble de la chaîne d’approvisionnement.
Correctifs de sécurité : l’autre voie, une pull request par paquet vulnérable.
Dépannage : quand des PR ne sont pas ouvertes ou qu’une exécution échoue.
Webhooks : les PR de Renovate déclenchent les mêmes événements webhook pull_request que toute autre PR.

Dépendances transitives Fusion