Fusion

Chaque pull request de dépendance soit attend qu’une personne la relise et la fusionne, soit est armée pour fusionner d’elle-même une fois ses vérifications requises réussies. Cela dépend de la voie, du type de mise à jour et de vos paramètres.

Correctifs de sécurité : Quand les correctifs sont fusionnés

Sécurité › Corriger › Mises à jour des dépendances › Correctifs de sécurité → Quand les correctifs sont fusionnés (merge dans les paramètres) a deux valeurs :

• Attendre la revue (review), la valeur par défaut. Une personne relit et fusionne.
• Fusionner quand les vérifications passent (when_green). La pull request est armée pour fusionner une fois ses vérifications requises réussies.

Avec Fusionner quand les vérifications passent, fremforge arme une pull request de correctif de sécurité pour qu’elle fusionne une fois ses vérifications requises réussies :

• Jamais pour un correctif qui franchit une version majeure. Celui-là attend toujours une revue.
• Jamais pendant un gel des versions.
• En dehors de votre fenêtre de fusion, uniquement pour un correctif d’une vulnérabilité connue comme exploitée.
• Jamais pour un paquet à fort rayon d’impact dans une organisation qui a elle-même activé Fusionner quand les vérifications passent.

Paquets à fort rayon d’impact

Environ 30 paquets d’authentification, de cryptographie, de base de données, d’ORM et de KMS cloud ne fusionnent jamais d’eux-mêmes un correctif de sécurité dans une organisation qui a elle-même activé Fusionner quand les vérifications passent ; ces correctifs attendent une revue. Les organisations dont les pull requests de sécurité Renovate fusionnaient d’elles-mêmes avant le 2026-10-14 ont été passées à Fusionner quand les vérifications passent en conservant ce comportement : les correctifs de ces paquets fusionnent aussi. Les paramètres l’indiquent par high_blast_radius_exempt: true.

Attendre la revue

Avec Attendre la revue, rien n’est armé. Une fusion automatique armée par fremforge ou par le bot est annulée ; celle qu’une personne a armée sur la pull request est laissée telle quelle.

Les pull requests de sécurité propres à Renovate hébergé

Le même paramètre décide des pull requests de sécurité propres à Renovate hébergé tant qu’elles servent encore l’organisation (lane_owner: renovate) : avec Fusionner quand les vérifications passent, elles fusionnent d’elles-mêmes lorsque la CI est verte, comme le faisait l’ancien commutateur de fusion automatique Security updates. Chaque organisation qui avait ce commutateur activé, ce qui était le cas par défaut pour toute organisation inscrite, a été passée à Fusionner quand les vérifications passent le 2026-10-14, si bien que ses pull requests de sécurité Renovate ont continué à fusionner et que rien n’a changé pour elle. Les nouvelles organisations démarrent sur Attendre la revue.

Organisations basculées le 2026-10-14

Pour une organisation passée à Fusionner quand les vérifications passent le 2026-10-14 (high_blast_radius_exempt: true), les pull requests de correctif de sécurité ouvertes à partir d’un résultat, par un clic ou automatiquement, attendent une revue jusqu’à ce que ses Correctifs de sécurité prennent le relais des pull requests de sécurité propres à Renovate hébergé. D’ici là, le paramètre ne s’applique qu’à ces pull requests Renovate, exactement comme avant. La prise de relais est une bascule distincte et auditée (voir Prendre le relais de Renovate) ; à partir de là, les pull requests de correctif suivent Quand les correctifs sont fusionnés, selon les règles ci-dessus, à mesure qu’elles remplacent celles de Renovate.

Une organisation qui active elle-même Fusionner quand les vérifications passent l’obtient immédiatement pour les pull requests de correctif, les paquets à fort rayon d’impact restant soumis à revue. Une fois que la voie des Correctifs de sécurité a pris le relais, Renovate n’ouvre plus que des mises à jour de version.

Approbations requises

Une pull request armée par un propriétaire de l’organisation, ou ouverte par un bot système de fremforge tel que <org>-fremforge-bot-deps, fusionne lorsque les vérifications sont vertes, même sur un dépôt qui exige une revue d’approbation. Fusionner quand les vérifications passent fusionne donc réellement sans intervention humaine sur de tels dépôts, comme l’ont fait jusqu’ici les pull requests de sécurité de Renovate. Choisissez Attendre la revue si chaque changement de dépendance doit être vu par une personne.

Mises à jour de version

Les mises à jour courantes suivent les niveaux de Renovate hébergé :

• Les mises à jour de correctif, d’épinglage et de digest fusionnent automatiquement lorsque la CI est verte, par défaut (automerge_patch).
• Les mises à jour mineures fusionnent automatiquement si vous l’activez (automerge_minor).
• Les mises à jour majeures attendent votre approbation sur le Dependency Dashboard (major_approval).
• Environ 30 paquets à fort rayon d’impact ne fusionnent jamais automatiquement une mise à jour courante.

Les règles de votre renovate.json sont appliquées après cette politique. Voir Mises à jour de version.

Fenêtre de fusion

Un propriétaire peut limiter les moments où les pull requests de dépendances sont armées pour fusionner, en heures UTC entières sur des jours de la semaine choisis (merge_window dans les paramètres des Mises à jour de version). En dehors de la fenêtre, rien n’est armé, 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 correctif de sécurité pour une CVE exploitée dans la nature est armé en dehors de la fenêtre, si bien qu’il fusionne dès que ses vérifications passent. Seule la fenêtre est ignorée.

Gel des versions

Un dépôt qui a un ticket ouvert portant le label release-freeze est gelé. Rien n’y est armé pour fusionner, pas même un correctif d’une vulnérabilité connue comme exploitée, et une vérification qui échoue compte comme un gel. Les pull requests sont tout de même ouvertes, si bien que le correctif est prêt à la fin du gel.