chore(deps): own the Renovate policy in-repo and fix inherited config gaps

[cubahno]

Takes ownership of this repo's Renovate policy and fixes three problems the inherited config was causing.

Why

renovate.json extended local>oapi-codegen/renovate-config — a public repo owned by the upstream oapi-codegen org, not doordash-oss — tracked at its unpinned default branch, chaining further to github>oapi-codegen/renovate-config:user. Anyone with write access there changes how dependencies are updated in this repo. That is the same mutable-reference exposure #130 just removed from the workflows, one level up.

This inlines the preset's contents so the policy is reviewable here. Renovate's own built-in presets (config:best-practices, helpers:pinGitHubActionDigestsToSemver) stay referenced, since depending on renovatebot is unavoidable when using Renovate at all. No behaviour from the upstream preset is dropped except the two managers that never matched this repo (see below).

What else this fixes

1. The Dependency Dashboard issues could not be closed (#90, #93)

Renovate treats the dashboard as a managed artifact and reopens it on the next run:

#90  closed 2026-08-08 11:28 → reopened 12:01 by doordash-renovate-staging[bot]
#90  closed 2026-08-13 17:22 → reopened 17:22 by doordash-renovate-staging[bot]   (11s later)
#93  closed 2026-08-08 11:28 → reopened 12:01 by doordash-renovate[bot]
#93  closed 2026-08-13 17:22 → reopened 17:23 by doordash-renovate[bot]

"dependencyDashboard": false is the actual off switch. This closes both, since both installations read this file.

2. Root-module bumps failed CI every time, by construction

examples/ carries replace github.com/doordash-oss/oapi-codegen-dd/v3 => ../, so its go.sum goes stale whenever a root dependency moves. The inherited postUpdateOptions: ["gomodTidy"] does tidy — but only the module it updated. That is why #106 and #113 sat red for two weeks with:

go: updates to go.mod needed; to update it:
	go mod tidy
make[1]: *** [Makefile:8: generate] Error 1

Adding groupName: "go modules" to the gomod rule keeps both modules in one branch, so gomodTidy runs across both. It also collapses what was ten simultaneous open go.mod PRs into one, which is what #129 did by hand.

3. golangci-lint was never tracked

The inherited manager looked for a curl .../golangci-lint/install.sh line. This repo uses go install ...@v2.12.2 (Makefile:24), so nothing matched and the pin was silently unmanaged — it sat at v2.12.2 while v2.13.2 exists. That is why the Go 1.27 attempt in #122 walked into a staticcheck IR panic with no advance warning.

Replaced with a manager that matches the real line. Verified against the actual Makefile:

pattern: go install github\.com/golangci/golangci-lint/v2/cmd/golangci-lint@(?<currentValue>v[^\s]+)
  match: go install github.com/golangci/golangci-lint/v2/cmd/golangci-lint@v2.12.2
  currentValue: v2.12.2

4. The Go-directive guard now covers CI

The inherited config already intends this — it carries constraintsFiltering: "strict" described as "Ensure that dependency updates do not bump the go directive". But that rule scopes to matchManagers: ["gomod"], and #122 bumped go-version in ci.yml, which the github-actions manager owns (depName: go, depType: uses-with, per #122's own body). So the guard existed and simply did not reach CI. The new rule closes that gap.

Dropped

Two inherited custom managers that match nothing in this repo:

• the curl install.sh Makefile manager (replaced, above)
• a manager for # yaml-language-server: $schema=https://raw.githubusercontent.com/oapi-codegen/oapi-codegen/.... This repo uses relative schema paths (../../configuration-schema.json), so it never matched.

Verification

renovate-config-validator (renovate@latest, as repo config):

 INFO: Validating renovate.json
 INFO: Config validated successfully against 1 file(s)

The custom manager regex was checked against the real Makefile under node (Renovate's regex flavour), output above.

Not addressed here

Two Renovate apps are installed on this repo, doordash-renovate and doordash-renovate-staging. That is why there were two dashboards, and why #115/#131 duplicated #116-#121: each installation keeps its own PR state, so closing one app's PR does not stop the other proposing the same update. Turning off the dashboard hides the symptom; uninstalling one app is a GitHub settings change and the real fix.

Also still unpinned and therefore unmanageable by Renovate: gosec@latest (ci.yml:49) and go-licenses@latest (Makefile:112).

🤖 Generated with Claude Code