fix(renovate): the config was INVALID, so the first manual run errored out #79

Merged
jakman85 merged 1 commits from fix/renovate-invalid-config into main 2026-10-18 14:29:34 +00:00
Owner

Your manual Renovate run failed because the config was never valid

renovate.json carried five pseudo-comment keys — _comment, _kubernetes_comment, _unmanageable_comment, _ignorePaths_comment, _docker_comment — because JSON has no comments. Renovate rejects unknown top-level options, so the whole config failed validation. Proven with the official validator, not inferred:

$ podman run --rm -v "$PWD/renovate.json:/tmp/renovate.json:ro,Z" \
    ghcr.io/renovatebot/renovate renovate-config-validator /tmp/renovate.json
ERROR: Found errors in configuration
  Invalid configuration option: _comment
  Invalid configuration option: _docker_comment
  Invalid configuration option: _ignorePaths_comment
  Invalid configuration option: _kubernetes_comment
  Invalid configuration option: _unmanageable_comment

This is the second independent reason Renovate had never worked, on top of PR #77's cron firing outside renovate.json's own schedule window. Either alone was sufficient to produce "nothing ever happens"; PR #73 shipped both. Both must merge before Renovate can run.

Fix: renovate.json → renovate.json5

JSON5 permits real // comments, and Renovate discovers renovate.json5 natively — nothing in .gitea/ or ci/ pins the old filename (only prose inside comments), and no RENOVATE_CONFIG_FILE is set. Every word of the original rationale is preserved as comments positioned next to what they explain, which flattening into a description string would have lost.

A header on the new file records the failure, the validator command, and an instruction to run it before committing — this class of bug is invisible to the repo's gate.

Verified the conversion lost nothing

Checked programmatically against git show HEAD:renovate.json:

non-comment keys before / after 18 / 18
missing keys none
extra keys none
keys whose value changed none
comment lines preserved 74
docker: {enabled: true} still present

The validator now returns INFO: Config validated successfully against 1 file(s). It also prints a normalisation diff mentioning docker — that is its own migration suggestion, not a removal, which the key-by-key comparison above confirms.

A suspicion disproved

enabledManagers containing bare regex was suspected of needing to be custom.regex, which would have silently disabled every inline # renovate: marker in the tree — including the external-snapshotter newTag pin #73 flagged as probably inert. The validator accepts regex. Unfounded, and deliberately left unchanged rather than "fixed".

Not verified

  • Renovate has still never completed a run. This removes one blocker, #77 the other. Neither is merged, so no successful run has been observed — I can only say these two defects are fixed, not that the bot works.
  • I did not re-run the workflow after the fix. The honest test is workflow_dispatch with dry_run: true once both merge.
  • Whether the managers extract anything. A valid config matching no files is still a no-op. Only the dry-run log's per-manager dependency counts prove the managerFilePatterns are right, and I have not seen them.
  • Whether the workflow's pinned Renovate version honours renovate.json5. JSON5 discovery is long-standing and the validator accepted the file, but the image tag was not cross-checked against the version that added it.
  • Nothing in the gate catches an invalid Renovate config, so this would have recurred silently. A one-line L0 check shelling out to renovate-config-validator would close it — not written here, and conformance/** is a sensitive path.

Local gate: rc 3, zero failures; only gitea-settings (CI-only token) and L2/L3 conformance (no cluster) did not run.

Full detail: decisions/2026-10-18-renovate-invalid-config.md

🤖 Generated with Claude Code

## Your manual Renovate run failed because the config was never valid `renovate.json` carried five pseudo-comment keys — `_comment`, `_kubernetes_comment`, `_unmanageable_comment`, `_ignorePaths_comment`, `_docker_comment` — because JSON has no comments. **Renovate rejects unknown top-level options**, so the whole config failed validation. Proven with the official validator, not inferred: ``` $ podman run --rm -v "$PWD/renovate.json:/tmp/renovate.json:ro,Z" \ ghcr.io/renovatebot/renovate renovate-config-validator /tmp/renovate.json ERROR: Found errors in configuration Invalid configuration option: _comment Invalid configuration option: _docker_comment Invalid configuration option: _ignorePaths_comment Invalid configuration option: _kubernetes_comment Invalid configuration option: _unmanageable_comment ``` **This is the second independent reason Renovate had never worked**, on top of PR #77's cron firing outside `renovate.json`'s own schedule window. Either alone was sufficient to produce "nothing ever happens"; PR #73 shipped both. **Both must merge before Renovate can run.** ## Fix: `renovate.json` → `renovate.json5` JSON5 permits real `//` comments, and Renovate discovers `renovate.json5` natively — nothing in `.gitea/` or `ci/` pins the old filename (only prose inside comments), and no `RENOVATE_CONFIG_FILE` is set. Every word of the original rationale is preserved **as comments positioned next to what they explain**, which flattening into a `description` string would have lost. A header on the new file records the failure, the validator command, and an instruction to run it before committing — this class of bug is invisible to the repo's gate. ## Verified the conversion lost nothing Checked programmatically against `git show HEAD:renovate.json`: | | | |---|---| | non-comment keys before / after | **18 / 18** | | missing keys | **none** | | extra keys | **none** | | keys whose value changed | **none** | | comment lines preserved | **74** | | `docker: {enabled: true}` | still present | The validator now returns `INFO: Config validated successfully against 1 file(s)`. It also prints a normalisation diff mentioning `docker` — that is its own migration suggestion, not a removal, which the key-by-key comparison above confirms. ## A suspicion disproved `enabledManagers` containing bare `regex` was suspected of needing to be `custom.regex`, which would have **silently disabled every inline `# renovate:` marker in the tree** — including the `external-snapshotter` `newTag` pin #73 flagged as probably inert. The validator accepts `regex`. Unfounded, and deliberately left unchanged rather than "fixed". ## Not verified - **Renovate has still never completed a run.** This removes one blocker, #77 the other. Neither is merged, so **no successful run has been observed** — I can only say these two defects are fixed, not that the bot works. - **I did not re-run the workflow after the fix.** The honest test is `workflow_dispatch` with `dry_run: true` once both merge. - **Whether the managers extract anything.** A valid config matching no files is still a no-op. Only the dry-run log's per-manager dependency counts prove the `managerFilePatterns` are right, and I have not seen them. - **Whether the workflow's pinned Renovate version honours `renovate.json5`.** JSON5 discovery is long-standing and the validator accepted the file, but the image tag was not cross-checked against the version that added it. - **Nothing in the gate catches an invalid Renovate config**, so this would have recurred silently. A one-line L0 check shelling out to `renovate-config-validator` would close it — not written here, and `conformance/**` is a sensitive path. Local gate: **rc 3, zero failures**; only `gitea-settings` (CI-only token) and L2/L3 `conformance` (no cluster) did not run. Full detail: `decisions/2026-10-18-renovate-invalid-config.md` 🤖 Generated with [Claude Code](https://claude.com/claude-code)
gitea-admin added 1 commit 2026-10-18 08:15:01 +00:00
fix(renovate): the config was INVALID, so the first manual run errored out
gate / gate (pull_request) Successful in 1m55s
gate / conformance (pull_request) Has been skipped
713b0c3dba
The operator ran the Renovate workflow manually and it failed. The cause is not
the workflow: renovate.json was never a valid Renovate config. It carried five
pseudo-comment keys (_comment, _kubernetes_comment, _unmanageable_comment,
_ignorePaths_comment, _docker_comment) because JSON has no comments, and
Renovate REJECTS unknown top-level options. Proven with the official validator:

  ERROR: Found errors in configuration
    Invalid configuration option: _comment
    Invalid configuration option: _docker_comment
    Invalid configuration option: _ignorePaths_comment
    Invalid configuration option: _kubernetes_comment
    Invalid configuration option: _unmanageable_comment

This is the SECOND independent reason Renovate never worked, on top of PR #77's
cron firing outside renovate.json's own schedule window. Either alone was enough
to produce "nothing ever happens"; #73 shipped both.

Converted renovate.json -> renovate.json5. JSON5 permits real // comments and
Renovate discovers renovate.json5 natively; nothing in .gitea/ or ci/ pins the
old filename and no RENOVATE_CONFIG_FILE is set. Every word of the original
rationale is preserved as positioned comments (74 comment lines) rather than
flattened into a description string.

Verified the conversion dropped nothing: 18 non-comment keys before and after,
no missing/extra keys, no changed values, docker: {enabled: true} still present.
The validator now returns "Config validated successfully".

DISPROVED while here: `enabledManagers` containing bare `regex` was suspected of
needing to be `custom.regex` (which would silently disable every inline
`# renovate:` marker). The validator accepts `regex`; unfounded, unchanged.

Renovate has still never completed a run -- this fixes one of two blockers and
nothing in the gate catches an invalid config. See the handoff.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
jakman85 approved these changes 2026-10-18 08:18:59 +00:00
jakman85 merged commit 1301af9a4c into main 2026-10-18 14:29:34 +00:00
Sign in to join this conversation.
No Reviewers
2 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Home-Network/home-network-k3s-impl#79