feat: automerge security (vulnerability) updates on green CI #2

2026-07-25T00:24:00Z

mars3142 commented

2026-07-25 00:24:00 +00:00

Problem

Security PRs raised through Renovate's vulnerabilityAlerts have no automerge in the preset — only npm devDependencies, CI actions and lockfile maintenance automerge. So security fixes sit open until merged by hand.

Live example: mars3142/blog-svelte has two open [SECURITY] PRs — #36 (@sveltejs/kit) and #35 (sharp). #35's CI is already green and it still sits open, purely because nothing arms automerge for it.

These are the updates that should land fastest, not slowest.

Change

   "vulnerabilityAlerts": {
     "minimumReleaseAge": null,
-    "schedule": ["at any time"]
+    "schedule": ["at any time"],
+    "automerge": true
   },

platformAutomerge: true (already set) means Gitea still only merges once the required checks pass — no green CI, no merge.
vulnerabilityAlerts settings override the per-repo group rules, so a security bump of e.g. @sveltejs/kit automerges even though the normal svelte + build toolchain group is deliberately review-only — Renovate splits vulnerability updates into their own branch anyway.
Scope is unchanged: this only touches updates Renovate flags as vulnerabilities.

Effect on the open blog-svelte PRs

On its next run for these repos (vulnerabilityAlerts is scheduled "at any time"), Renovate re-evaluates the existing PRs and arms platform automerge on them — #35 then merges immediately (already green), #36 once its check passes.

🤖 Generated with Claude Code

https://claude.ai/code/session_018dVH5RiPsudxH4wV74ucEs

## Problem Security PRs raised through Renovate's `vulnerabilityAlerts` have **no automerge** in the preset — only npm devDependencies, CI actions and lockfile maintenance automerge. So security fixes sit open until merged by hand. Live example: `mars3142/blog-svelte` has two open `[SECURITY]` PRs — #36 (`@sveltejs/kit`) and #35 (`sharp`). #35's CI is already **green** and it still sits open, purely because nothing arms automerge for it. These are the updates that should land *fastest*, not slowest. ## Change ```diff "vulnerabilityAlerts": { "minimumReleaseAge": null, - "schedule": ["at any time"] + "schedule": ["at any time"], + "automerge": true }, ``` - `platformAutomerge: true` (already set) means Gitea still only merges once the **required checks pass** — no green CI, no merge. - `vulnerabilityAlerts` settings override the per-repo group rules, so a security bump of e.g. `@sveltejs/kit` automerges even though the normal `svelte + build toolchain` group is deliberately review-only — Renovate splits vulnerability updates into their own branch anyway. - Scope is unchanged: this only touches updates Renovate flags as vulnerabilities. ## Effect on the open blog-svelte PRs On its next run for these repos (vulnerabilityAlerts is scheduled "at any time"), Renovate re-evaluates the existing PRs and arms platform automerge on them — #35 then merges immediately (already green), #36 once its check passes. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_018dVH5RiPsudxH4wV74ucEs

mars3142 added 1 commit 2026-07-25 00:24:01 +00:00

feat: automerge security (vulnerability) updates on green CI d626f3bc57

Security PRs raised via vulnerabilityAlerts had no automerge, so they
sat open until merged by hand — e.g. blog-svelte #35 (sharp) stayed open
even though CI was green. These are exactly the updates that should land
fastest, and platformAutomerge still gates them on the required checks.

Add automerge to the vulnerabilityAlerts block. It overrides the per-repo
group rules (e.g. the ungrouped 'svelte + build toolchain'), because
Renovate splits vulnerability updates into their own branches anyway.

Signed-off-by: Peter Siegmund <peter.siegmund@entwicklung.eq-3.de>

mars3142 merged commit d8542a5dfe into main

2026-07-28 18:39:24 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: mars3142/renovate-config#2