What happened
Renovate created standalone security PRs #3473, #3474, and #3475 to bump go-git/go-git/v5 from v5.19.1 to v5.19.2, patching CVE-2026-71556 (CVSS 7.1 High) and CVE-2026-71557 (CVSS 6.3 Medium). The review agent approved all three within ~7 minutes and applied ready-for-merge. On 2026-08-08, Renovate autoclosed all three PRs because the same version bump was already present in grouped patch PRs (e.g., PR #3019 on main). PR #3019 has been open since October 2025 with failing Test, Lint, and Acceptance checks, so the security fix cannot merge through it. This is a recurring pattern: the identical sequence occurred with go-git v5.19.1 in April 2026 (PRs #3250-3253 autoclosed, manual PR #3335 needed weeks later to actually land the fix on June 12).
What could go better
High confidence: standalone security PRs should not be grouped with large, long-failing patch bundles. The current Renovate config groups all Go module patch updates together, which means a 6-line security fix gets absorbed into a multi-dependency bundle that has been failing CI for months. The security fix was independently approved and ready to merge, but Renovate's deduplication closed it in favor of the blocked grouped PR. This has now happened at least twice in this repo with the same dependency, each time requiring manual intervention weeks later. The agent workflow itself was correct — this is a repo-level configuration issue upstream of the agent pipeline.
Proposed change
Add a packageRules entry in the Renovate config (likely .github/config/renovate/renovate.json or the repo's renovate.json) to exclude vulnerability alerts from grouped patch update PRs, so security fixes remain standalone and can merge independently. Example rule:
{
"matchManagers": ["gomod"],
"isVulnerabilityAlert": true,
"groupName": null,
"groupSlug": null
}
This ensures Renovate does not deduplicate security PRs against grouped PRs that may have unrelated CI failures. Note: issue #3458 documents intentional Renovate exclusions for agent guidance — this proposal addresses a demonstrated, recurring security gap rather than a stylistic preference. Both CVEs (CVSS 7.1 and 6.3) remain unpatched on main, release-v0.7, and release-v0.8 as of this writing.
Validation criteria
The next time Renovate creates a vulnerability/security PR for a Go module, it should remain a standalone PR and not be autoclosed by Renovate's deduplication logic. Verify by confirming: (1) the security PR title includes '[SECURITY]' or '[VULNERABILITY]', (2) it is not grouped into the 'Update go modules (patch)' PR, and (3) it remains open and mergeable independently of the grouped patch PR's CI status. Historical validation: if this rule had been in place, PRs #3473-3475 and #3250-3253 would not have been autoclosed.
Generated by retro agent from #3474
What happened
Renovate created standalone security PRs #3473, #3474, and #3475 to bump
go-git/go-git/v5from v5.19.1 to v5.19.2, patching CVE-2026-71556 (CVSS 7.1 High) and CVE-2026-71557 (CVSS 6.3 Medium). The review agent approved all three within ~7 minutes and appliedready-for-merge. On 2026-08-08, Renovate autoclosed all three PRs because the same version bump was already present in grouped patch PRs (e.g., PR #3019 on main). PR #3019 has been open since October 2025 with failing Test, Lint, and Acceptance checks, so the security fix cannot merge through it. This is a recurring pattern: the identical sequence occurred with go-git v5.19.1 in April 2026 (PRs #3250-3253 autoclosed, manual PR #3335 needed weeks later to actually land the fix on June 12).What could go better
High confidence: standalone security PRs should not be grouped with large, long-failing patch bundles. The current Renovate config groups all Go module patch updates together, which means a 6-line security fix gets absorbed into a multi-dependency bundle that has been failing CI for months. The security fix was independently approved and ready to merge, but Renovate's deduplication closed it in favor of the blocked grouped PR. This has now happened at least twice in this repo with the same dependency, each time requiring manual intervention weeks later. The agent workflow itself was correct — this is a repo-level configuration issue upstream of the agent pipeline.
Proposed change
Add a
packageRulesentry in the Renovate config (likely.github/config/renovate/renovate.jsonor the repo'srenovate.json) to exclude vulnerability alerts from grouped patch update PRs, so security fixes remain standalone and can merge independently. Example rule:{ "matchManagers": ["gomod"], "isVulnerabilityAlert": true, "groupName": null, "groupSlug": null }This ensures Renovate does not deduplicate security PRs against grouped PRs that may have unrelated CI failures. Note: issue #3458 documents intentional Renovate exclusions for agent guidance — this proposal addresses a demonstrated, recurring security gap rather than a stylistic preference. Both CVEs (CVSS 7.1 and 6.3) remain unpatched on main, release-v0.7, and release-v0.8 as of this writing.
Validation criteria
The next time Renovate creates a vulnerability/security PR for a Go module, it should remain a standalone PR and not be autoclosed by Renovate's deduplication logic. Verify by confirming: (1) the security PR title includes '[SECURITY]' or '[VULNERABILITY]', (2) it is not grouped into the 'Update go modules (patch)' PR, and (3) it remains open and mergeable independently of the grouped patch PR's CI status. Historical validation: if this rule had been in place, PRs #3473-3475 and #3250-3253 would not have been autoclosed.
Generated by retro agent from #3474