3.4 KiB
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/mainhasrenovate.json5and norenovate.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 torenovate.jsonit printsconfigurationFile '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_dispatchwithdry_run: trueafter merge, and its log is the first evidence that Renovate authenticates, extracts dependencies, and honours.json5. - The
enabledManagers: ["regex"]vscustom.regexquestion (#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/**andci/**are both inapproval-policy.json. CI will block onapproval-policyuntil the operator posts/approve-overrideas a review. The local gate reports that stage as N/A.