What happened
PR #3473 was a Renovate security update bumping go-git/go-git/v5 from v5.19.1 to v5.19.2, fixing CVE-2026-71556 (CVSS 7.1 High) and CVE-2026-71557 (CVSS 6.3 Medium). All CI checks passed, the review agent approved it twice, and the ready-for-merge label was applied with automerge enabled. Before the PR could merge, Renovate autoclosed it on Aug 8 and folded the update into the long-running grouped PR #3019 ("Update go modules (main) (patch)"), which has been open since October 2025 and contains dozens of dependency bumps.
This is a recurring pattern. The same thing happened with go-git v5.19.1: Renovate opened individual security PRs (#3250, #3252, #3253), all were autoclosed, and a maintainer eventually had to manually create PR #3335 to land the update. As of this retro, go.mod on main still shows go-git/go-git/v5 v5.19.1 — the v5.19.2 security fix has not been applied.
What could go better
The org-level Renovate config at conforma/.github/config/renovate/renovate.json has a grouping rule that groups all gomod updates together. This means security-specific PRs — which are small, focused, and ready to merge quickly — get absorbed into a large grouped PR that moves slowly because it accumulates many unrelated updates. The grouped PR becomes a bottleneck that blocks timely application of security fixes.
Confidence: High. The causal chain is clear and documented: (1) the grouping rule exists, (2) Renovate autoclosed the security PR because the update was folded into the group, (3) the grouped PR remains unmerged, (4) the same pattern recurred for v5.19.1. The only uncertainty is whether the grouping behavior is intentionally designed to include security updates — but the fact that a human had to manually work around it for v5.19.1 strongly suggests it is not intentional.
Note: Issue #3458 documents that Go version updates are intentionally excluded from Renovate automation. This proposal is about a different concern — security vulnerability patches being blocked by dependency grouping, not about Go version management strategy.
Proposed change
Add a Renovate packageRules entry (either in the repo-level renovate.json or the org-level config at conforma/.github/config/renovate/renovate.json) that excludes vulnerability/security updates from the gomod grouping rule. For example:
{
"description": "Keep security/vulnerability updates as individual PRs for fast automerge",
"matchManagers": ["gomod"],
"isVulnerabilityAlert": true,
"groupName": null
}This rule should be placed before the existing gomod grouping rule so that security updates remain as standalone PRs that can pass CI and automerge independently, without being absorbed into the slow-moving grouped PR.
In the immediate term, a manual PR should be created to bump go-git to v5.19.2, as was done with PR #3335 for v5.19.1.
Validation criteria
The next Renovate-generated security/vulnerability PR for a Go module should remain open as an individual PR (not be autoclosed and folded into a grouped PR). Verify by checking that: (1) the PR is not renamed with '- autoclosed' suffix, (2) the PR merges independently if CI passes and review approves, and (3) the security fix appears on the target branch within 24 hours of the PR being opened.
Generated by retro agent from #3473
What happened
PR #3473 was a Renovate security update bumping
go-git/go-git/v5from v5.19.1 to v5.19.2, fixing CVE-2026-71556 (CVSS 7.1 High) and CVE-2026-71557 (CVSS 6.3 Medium). All CI checks passed, the review agent approved it twice, and theready-for-mergelabel was applied with automerge enabled. Before the PR could merge, Renovate autoclosed it on Aug 8 and folded the update into the long-running grouped PR #3019 ("Update go modules (main) (patch)"), which has been open since October 2025 and contains dozens of dependency bumps.This is a recurring pattern. The same thing happened with go-git v5.19.1: Renovate opened individual security PRs (#3250, #3252, #3253), all were autoclosed, and a maintainer eventually had to manually create PR #3335 to land the update. As of this retro,
go.modon main still showsgo-git/go-git/v5 v5.19.1— the v5.19.2 security fix has not been applied.What could go better
The org-level Renovate config at
conforma/.github/config/renovate/renovate.jsonhas a grouping rule that groups all gomod updates together. This means security-specific PRs — which are small, focused, and ready to merge quickly — get absorbed into a large grouped PR that moves slowly because it accumulates many unrelated updates. The grouped PR becomes a bottleneck that blocks timely application of security fixes.Confidence: High. The causal chain is clear and documented: (1) the grouping rule exists, (2) Renovate autoclosed the security PR because the update was folded into the group, (3) the grouped PR remains unmerged, (4) the same pattern recurred for v5.19.1. The only uncertainty is whether the grouping behavior is intentionally designed to include security updates — but the fact that a human had to manually work around it for v5.19.1 strongly suggests it is not intentional.
Note: Issue #3458 documents that Go version updates are intentionally excluded from Renovate automation. This proposal is about a different concern — security vulnerability patches being blocked by dependency grouping, not about Go version management strategy.
Proposed change
Add a Renovate
packageRulesentry (either in the repo-levelrenovate.jsonor the org-level config atconforma/.github/config/renovate/renovate.json) that excludes vulnerability/security updates from the gomod grouping rule. For example:{ "description": "Keep security/vulnerability updates as individual PRs for fast automerge", "matchManagers": ["gomod"], "isVulnerabilityAlert": true, "groupName": null }This rule should be placed before the existing gomod grouping rule so that security updates remain as standalone PRs that can pass CI and automerge independently, without being absorbed into the slow-moving grouped PR.
In the immediate term, a manual PR should be created to bump go-git to v5.19.2, as was done with PR #3335 for v5.19.1.
Validation criteria
The next Renovate-generated security/vulnerability PR for a Go module should remain open as an individual PR (not be autoclosed and folded into a grouped PR). Verify by checking that: (1) the PR is not renamed with '- autoclosed' suffix, (2) the PR merges independently if CI passes and review approves, and (3) the security fix appears on the target branch within 24 hours of the PR being opened.
Generated by retro agent from #3473