Files
home-network-k3s-impl/decisions/2026-10-29-renovate-config-filename.md
T
jakman85andClaude Opus 5.5 da1b36eb64
gate / gate (pull_request) Successful in 1m55s
gate / conformance (pull_request) Has been skipped
fix(renovate): pin renovate-version — the action's default (39) rejects renovate.json5
Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-10-29 21:49:38 -05:00

3.4 KiB
Raw Blame History

date, branch, title
date branch title
2026-10-29 fix/renovate-config-filename Renovate has failed every run since

What changed

.gitea/workflows/renovate.yaml — configurationFile: renovate.json → renovate.json5.

PR #79 (fix/renovate-invalid-config) renamed the config to renovate.json5 and did not update the one line in the workflow that names it. Measured 2026-10-29 from the Gitea Actions log of run 322 (task 513, schedule, 08:15 UTC):

Error: ENOENT: no such file or directory, stat '/workspace/Home-Network/home-network-k3s-impl/renovate.json'

Runs 315–322 (2026-10-22 → 10-29, every one listed) are all failure on the schedule event, each failing in about one second. Renovate never started. RENOVATE_TOKEN does exist as a repository Actions secret (listed by name via the API; value not read), so the token preflight passes and this filename is the only blocker observed.

ci/lint.sh — a new assertion after yamllint: every non-comment configurationFile: key in .gitea/workflows/*.y*ml must name a path that exists. This is valid YAML, so yamllint cannot see it, and the gate stayed green through 11 days of failures.

Second blocker, same PR: the workflow did not pin a Renovate version, so renovatebot/[email protected] ran its default, Renovate 39 (action.yml: renovate-version default: '39', read at that tag). renovate.json5 uses managerFilePatterns, which needs >= 40.2.0. Under 39.264.0 the validator rejects the config with five errors. This was found and reproduced by the image-pipeline worker (PR #81). #79 had validated against latest. Pinned renovate-version: 44.167.0, the version the config validates clean against per that worker.

What I verified

  • The root cause, from the run log quoted above, and that origin/main has renovate.json5 and no renovate.json (git ls-tree).
  • The new guard, both ways, run standalone: on this branch it prints workflow configurationFile references resolve, rc 0. With the line reverted to renovate.json it prints configurationFile 'renovate.json' does not exist in the repo, rc 1. My first version also matched its own explanatory comment in the workflow and failed. That is why the grep is anchored to non-comment lines.
  • Toolbox gate: result and rc are reported in the PR, not predicted here.

What I did NOT verify

  • The 39.x rejection and the 44.167.0 pass were not reproduced by me. I confirmed only the action's default ('39'). The validation results are the PR #81 worker's.
  • Renovate has still never completed a run. This removes the observed blocker. Others may follow it. The test is a workflow_dispatch with dry_run: true after merge, and its log is the first evidence that Renovate authenticates, extracts dependencies, and honours .json5.
  • The enabledManagers: ["regex"] vs custom.regex question (#73, #77) is still open. The same dry-run log answers it: look for the regex/custom manager's dependency-extraction count.
  • No alert for "Renovate keeps failing". The guard prevents this specific cause from recurring. Nothing notices a scheduled workflow that is red every day. That gap stays open.
  • Sensitive path. .gitea/** and ci/** are both in approval-policy.json. CI will block on approval-policy until the operator posts /approve-override as a review. The local gate reports that stage as N/A.