[tonygermano]

Summary

This PR adds a workflow, .github/workflows/renovate-config.yaml, that checks renovate.json with Renovate's own renovate-config-validator. Today a mistake in the config only shows up the next time Renovate runs on the repository, when it stops opening PRs or reports a config error. With this workflow, the PR that introduces the mistake gets a failing check.

• When it runs: on pull requests to main, and pushes to main, that change renovate.json or the workflow file. Other PRs don't run it. The workflow has contents: read permission only.
• How it runs: the validator comes from the official ghcr.io/renovatebot/renovate image, pinned by tag and digest. It's referenced as a docker:// step rather than a docker run command, so Renovate's github-actions manager keeps the image current alongside the other pinned actions. actions/checkout uses the same pinned commit as build.yaml.
• Flags: --strict --no-global renovate.json.

The check isn't meant to be required for merging. Like the main build, it relies on reviewers seeing the red X.

Why --no-global

Renovate has two kinds of configuration. A repository config (our renovate.json) is read from the repository being updated. A global config is set by whoever runs a self-hosted Renovate instance. Some options are only allowed in global config, for example allowedCommands, which controls which shell commands Renovate may run after an upgrade.

When the validator is given file names, it treats them as global config unless --no-global is passed. In that mode, global-only options pass validation even though a repository config isn't allowed to set them. --no-global validates the file as a repository config, which rejects those options. Claude confirmed this with a copy of our renovate.json with allowedCommands added: it passes without the flag, and with the flag it fails with "The "allowedCommands" option is a global option reserved only for Renovate's global configuration and cannot be configured within a repository's config file."

--strict makes the job fail on warnings and on options that need migration, not only on errors.

The workflow file has a comment explaining both flags.

Trade-off

Renovate publishes releases very often, so the pinned image will get an update PR every month under our monthly schedule, and new major versions need approval on the dependency dashboard.

Testing

Claude checked, running the validator from the pinned image with the same arguments as the workflow and the repository mounted read-only:

• renovate.json on main validates as repo config, and so does the one in Keep Guava on -jre and drop redundant Renovate groups #553.
• A renovate.json with a misspelled option (groupNam) fails with exit code 1 and names the option.
• The allowedCommands case above.

actionlint reports no problems in the workflow.

Not tested: the workflow itself on GitHub. It will run on this PR, since the PR changes the workflow file.

---

🤖 Drafted with Claude Code

[mgaffigan]

You might limit the check out to the target commit. I don't think that happens by default IIRC

Edit: it's the default. Never mind.

[github-actions]

Test Results

133 files  ±0  133 suites  ±0   4m 8s ⏱️ + 1m 15s
817 tests ±0  817 ✅ ±0  0 💤 ±0  0 ❌ ±0 
943 runs  ±0  937 ✅ ±0  6 💤 ±0  0 ❌ ±0 

Results for commit 390e4d3. ± Comparison against base commit 3c79615.

[tonygermano]

You might limit the check out to the target commit. I don't think that happens by default IIRC

I checked and our normal build workflow works the same way. The readme for the action says that only a single commit is checked out by default (fetch-depth=1). Good thought, though. It was still worth a look.