You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
MintMaker/Renovate created PR #296 on 2026-06-17 to bump gopkg.in/yaml.v2 from v2.4.0 to v3.0.1. In Go modules, gopkg.in/yaml.v2 and gopkg.in/yaml.v3 are separate modules with different import paths — a major version "update" is not a valid version bump but a module replacement requiring code changes. The PR was autoclosed and reopened 3 times over 74 days (closed 2026-07-27, reopened 2026-07-28, closed 2026-08-02, reopened 2026-08-03, finally closed 2026-08-30). All Prow CI checks failed each cycle (coverage, lint, images, e2e — example run). A parallel PR #308 proposes the same invalid bump for go.yaml.in/yaml/v2 to v3 and has been open 53+ days. PRs #294, #295, and #298 follow the same pattern for other Go modules (jsonpatch, json-patch, ginkgo). The Dependency Dashboard lists gopkg.in/yaml.v2 as abandoned and reports lookup failures for it. Across 30+ closed MintMaker dependency PRs, zero were merged.
What could go better
The Renovate configuration (.github/renovate.json) extends github>openshift/boilerplate//.github/renovate.json which allows major-version Go module bumps but labels them manual-review-required. For this repository, major-version bumps of indirect Go dependencies will never be mergeable without significant code changes — they change import paths, require updating all consumers, and often involve migrating to entirely different APIs. Creating these PRs wastes CI resources (each autoclose/reopen cycle triggers a full Prow suite), creates noise for maintainers, and clutters the PR list. I am confident in this assessment because: (1) the 0% merge rate across 30+ PRs is unambiguous, (2) Go module major version semantics are well-defined — vanity import paths like gopkg.in/yaml.v2 encode the major version, making automatic bumps impossible, and (3) the Dependency Dashboard itself flags these packages as problematic.
Proposed change
Add packageRules to .github/renovate.json to disable major-version updates for Go modules. This is a local override that keeps the inherited boilerplate config for minor/patch updates (which are grouped and can auto-merge) while suppressing the problematic major bumps:
Alternatively, if the team wants to see major bumps for direct dependencies but not indirect ones, use "matchDepTypes": ["indirect"] to limit the suppression. After applying, close the stale open PRs (#293 if it contains major bumps, #294, #295, #308, #310) that are blocked by the same issue.
What happened
MintMaker/Renovate created PR #296 on 2026-06-17 to bump
gopkg.in/yaml.v2from v2.4.0 to v3.0.1. In Go modules,gopkg.in/yaml.v2andgopkg.in/yaml.v3are separate modules with different import paths — a major version "update" is not a valid version bump but a module replacement requiring code changes. The PR was autoclosed and reopened 3 times over 74 days (closed 2026-07-27, reopened 2026-07-28, closed 2026-08-02, reopened 2026-08-03, finally closed 2026-08-30). All Prow CI checks failed each cycle (coverage, lint, images, e2e — example run). A parallel PR #308 proposes the same invalid bump forgo.yaml.in/yaml/v2to v3 and has been open 53+ days. PRs #294, #295, and #298 follow the same pattern for other Go modules (jsonpatch, json-patch, ginkgo). The Dependency Dashboard listsgopkg.in/yaml.v2as abandoned and reports lookup failures for it. Across 30+ closed MintMaker dependency PRs, zero were merged.What could go better
The Renovate configuration (
.github/renovate.json) extendsgithub>openshift/boilerplate//.github/renovate.jsonwhich allows major-version Go module bumps but labels themmanual-review-required. For this repository, major-version bumps of indirect Go dependencies will never be mergeable without significant code changes — they change import paths, require updating all consumers, and often involve migrating to entirely different APIs. Creating these PRs wastes CI resources (each autoclose/reopen cycle triggers a full Prow suite), creates noise for maintainers, and clutters the PR list. I am confident in this assessment because: (1) the 0% merge rate across 30+ PRs is unambiguous, (2) Go module major version semantics are well-defined — vanity import paths likegopkg.in/yaml.v2encode the major version, making automatic bumps impossible, and (3) the Dependency Dashboard itself flags these packages as problematic.Proposed change
Add
packageRulesto.github/renovate.jsonto disable major-version updates for Go modules. This is a local override that keeps the inherited boilerplate config for minor/patch updates (which are grouped and can auto-merge) while suppressing the problematic major bumps:{ "$schema": "https://docs.renovatebot.com/renovate-schema.json", "extends": [ "github>openshift/boilerplate//.github/renovate.json" ], "packageRules": [ { "matchManagers": ["gomod"], "matchUpdateTypes": ["major"], "enabled": false, "description": "Disable Go module major-version bumps — these change import paths and require manual code migration" } ] }Alternatively, if the team wants to see major bumps for direct dependencies but not indirect ones, use
"matchDepTypes": ["indirect"]to limit the suppression. After applying, close the stale open PRs (#293 if it contains major bumps, #294, #295, #308, #310) that are blocked by the same issue.Validation criteria
Generated by retro agent from #296