Add Renovate config (Gradle + Docker) with verification-metadata automation

[jonbartels]

Draft. Supersedes the Dependabot approach in #356, based on review feedback about the RCE/trust-anchor risk of auto-regenerating the Gradle verification metadata.

Summary

Configures Renovate for dependency updates (replacing the Dependabot approach), plus a hardened workflow to keep updates compatible with this repo's Gradle dependency verification.

• renovate.json — validated with renovate-config-validator
  • Monthly schedule; minimumReleaseAge: "2 days" (equivalent of Dependabot's cooldown)
  • Grouping by coherent project family, keyed deep so unrelated org.apache.* projects stay separate (org.apache.commons, org.apache.logging.log4j, …): aws-sdk, jetty, jersey, jackson, netty, log4j, apache-commons, test-tooling, plus a catch-all all-minor-and-patch (majors of ungrouped deps stay individual). Rule order accounts for Renovate's last-match-wins merge so family groups aren't swallowed by the catch-all.
  • prConcurrentLimit: 10, ecosystem labels (java/docker via addLabels), semantic commits, dependencyDashboard, osvVulnerabilityAlerts
  • Docker Dockerfile picked up automatically by Renovate's dockerfile manager
• .github/workflows/renovate-verification-metadata.yaml — Dependabot/Renovate bumps that touch pinned deps would fail CI on stale checksums, and the file cannot always be regenerated by the bot. This workflow regenerates gradle/verification-metadata.xml on renovate/** branches using split privilege:
  • regen job: contents: read, no secrets — runs the cold-cache build dist --write-verification-metadata sha256 (executes untrusted, newly-bumped code, but has nothing to steal and cannot push), uploads the file as an artifact.
  • commit job: contents: write, runs no dependency code — downloads the artifact and commits it. The writable token never coexists with untrusted execution.

Design notes

• PGP signature verification was evaluated and deliberately not adopted. A trial pgp,sha256 regen produced only partial signature coverage (~50 publisher keys were un-fetchable from keyservers) and would make CI depend on flaky keyservers at verify time unless a keyring is vendored. We kept verify-metadata=true (sha256). Residual auto-regen risk is mitigated by the split-privilege workflow + 2-day minimumReleaseAge.
• The split-privilege design is the fix for the RCE/token-theft concern raised on Add Dependabot config (Gradle + Docker) with grouping and verification-metadata automation #356: untrusted dependency code no longer runs alongside a writable token.

⚠️ Manual configuration required (repo admin)

1. Install the Mend Renovate GitHub App on OpenIntegrationEngine/engine and merge its onboarding PR.
2. Turn off Dependabot version updates (there is no dependabot.yml on main; if Add Dependabot config (Gradle + Docker) with grouping and verification-metadata automation #356 is not merged, nothing to remove — just ensure no org-level Dependabot config re-enables it).
3. Labels dependencies / java / docker already exist in the repo — no action.
4. Ensure Actions has read/write permissions (or rely on the workflow's job-level permissions:) so the commit job can push.

✅ Validation gate before this leaves draft

Confirm on a real Renovate Gradle PR whether Mend-hosted Renovate regenerates verification-metadata.xml itself:

• If yes: delete .github/workflows/renovate-verification-metadata.yaml (redundant).
• If no: keep it — it regenerates the file with the token isolated from the untrusted build.

🤖 Generated with Claude Code

[github-actions]

Test Results

654 tests  ±0   654 ✅ ±0   3m 31s ⏱️ +48s
108 suites ±0     0 💤 ±0 
108 files   ±0     0 ❌ ±0 

Results for commit e53d7d3. ± Comparison against base commit a08c114.

♻️ This comment has been updated with latest results.

[jonbartels]

Here is an example of what we get out of renovate. https://github.com/jonbartels/oie-engine/pulls/app%2Frenovate

This doesn't do the grouping like dependa does I'll work on configuring it.

[mgaffigan]

Can we remove this? Either renovate does the thing or it doesn't.

[jonbartels]

I need help. I'm unsure what is and is not required and if I'm reading the right docs.

I don't think we can. I ran a few experiments against my fork after reading - https://docs.renovatebot.com/modules/manager/gradle/#dependency-verification. jonbartels#24

I also read renovatebot/renovate#32747 and renovatebot/renovate#29784

AI summary follows. It has to do with caching and how mend works when its cloud hosted.

Verdict: on Mend-hosted Renovate, the workflow is required. Confirmed live.

What the experiment showed (fork PR #24): With the regen workflow removed from main, Renovate's own netty-codec bump — its real commit, version-only, no metadata — hit CI and failed exactly where predicted:

> Dependency verification failed for configuration ':server:runtimeClasspath'
    - netty-codec-4.1.133.Final.jar / .pom  →  BUILD FAILED

Why Renovate can't do it on Mend (the full causal chain, now proven end to end):
1. Renovate's built-in command is capable — locally it produced a byte-identical result to your workflow, including the netty-parent POM.
2. But that only works from a cold Gradle cache. Mend-hosted Renovate runs with a warm/persistent cache, and per your own CONTRIBUTING.md, a warm cache "skips re-resolving already-cached parent POMs, so they never get recorded."
3. So on Mend, netty's shared netty-parent lineage was already cached → not recorded → Renovate's PR shipped incomplete → CI red. (com.sun.mail was the lone success only because it and its parent were genuinely new to Mend's cache.)
4. There's no lever on hosted Renovate to force a cold cache or add --refresh-dependencies — so the workflow's GRADLE_USER_HOME=$(mktemp -d) cold run is doing something Mend structurally can't.

Cleanup done:
- Experiment PR #24 closed with a summary comment.
- Fork main force-restored to its pre-experiment commit (0f5d74b8c) — the workflow is back, so your live Renovate PRs won't break.
- Experiment branch and local temp branches deleted.
- Your OIE branch (add-renovate-config, PR #358) and its config are untouched, tuning options intact.

Bottom line for your goal: you can't drop the workflow while on Mend-hosted without breaking Gradle verification. The only way to eliminate it is to self-host Renovate and run its command against a cold cache / --refresh-dependencies — which is just a different workflow with worse isolation. My recommendation stands: keep the split-privilege workflow on Mend. Want me to note this conclusion in PR #358's description so reviewers don't re-litigate it?```