fix(renovate): the cron fired outside Renovate's own window, so it would never open a PR #77

2026-10-18T08:05:09Z

gitea-admin commented

2026-10-18 08:05:09 +00:00

The scheduled run could never have opened a PR

.gitea/workflows/renovate.yaml shipped (PR #73) with cron: "15 3 * * *". Gitea Actions cron is UTC, and renovate.json carries "schedule": ["after 3am and before 6am"] with "timezone": "America/New_York" — and that inner schedule is authoritative: Renovate re-checks it and declines to open PRs outside it.

cron 03:15 UTC  ->  23:15 EDT, the PREVIOUS EVENING in New York
window          ->  03:00-06:00 local
inside?         ->  NO (3h45m before the window opens)

The original comment claimed the cron was "slightly ahead of the repo window". It is 3h45m behind, on the previous day. Every nightly run would have started, logged "not within schedule", opened zero PRs and exited successfully — a green tick forever, indistinguishable from "nothing needed updating", hiding the ~30 pending updates PR #73 was written to surface.

Fixed to `15 8 * * *`, chosen to survive DST

	local window	in UTC
EDT (UTC-4, Mar–Nov)	03:00–06:00	07:00–10:00
EST (UTC-5, Nov–Mar)	03:00–06:00	08:00–11:00

08:15 UTC is inside both — verified by computation at both extremes (04:15 EDT in July, 03:15 EST in December). A cron cannot follow DST, so this is the only value that needs no edit at either switchover.

Also confirmed while here: RENOVATE_TOKEN now exists as a repository Actions secret, so the workflow's fail-hard preflight will pass. It did not when #73 was authored.

Still unresolved — the likelier remaining bug

renovate.json lists enabledManagers: [..., 'regex', ...] and defines customManagers (the correct modern key; regexManagers is absent, which is right). But modern Renovate names the custom manager custom.regex in enabledManagers, not bare regex. If the bare name is ignored, every inline # renovate: marker in the tree does nothing — including the external-snapshotter newTag pin #73 flagged as probably inert.

Deliberately not changed: guessing at a config key that could fail validation and take the whole run down is worse than a question one dry run answers. Dispatch with dry_run: true and log_level: debug, then look for a per-manager dependency-extraction count and any validation warning naming regex.

Not verified

Renovate has still never executed. This fixes when it runs, not whether it works.
A dry run outside the local window is less informative than it looks — Renovate honours its schedule even in dry-run, so it will log "not within schedule" and show you nothing. Dispatch inside 03:00–06:00 New York, or override the schedule for that run.
No alert fires if the schedule stops firing — a disabled runner, expired token or deleted secret produces no signal at all. #73 recorded this gap; it is still open.
No conformance test asserts the cron falls inside renovate.json's window, so this exact bug can return.

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-cron-window.md

🤖 Generated with Claude Code

## The scheduled run could never have opened a PR `.gitea/workflows/renovate.yaml` shipped (PR #73) with `cron: "15 3 * * *"`. Gitea Actions cron is **UTC**, and `renovate.json` carries `"schedule": ["after 3am and before 6am"]` with `"timezone": "America/New_York"` — and **that inner schedule is authoritative**: Renovate re-checks it and declines to open PRs outside it. ``` cron 03:15 UTC -> 23:15 EDT, the PREVIOUS EVENING in New York window -> 03:00-06:00 local inside? -> NO (3h45m before the window opens) ``` The original comment claimed the cron was "slightly ahead of the repo window". It is 3h45m *behind*, on the previous day. Every nightly run would have started, logged "not within schedule", opened **zero** PRs and exited **successfully** — a green tick forever, indistinguishable from "nothing needed updating", hiding the ~30 pending updates PR #73 was written to surface. ## Fixed to `15 8 * * *`, chosen to survive DST | | local window | in UTC | |---|---|---| | EDT (UTC-4, Mar–Nov) | 03:00–06:00 | 07:00–10:00 | | EST (UTC-5, Nov–Mar) | 03:00–06:00 | 08:00–11:00 | `08:15 UTC` is inside **both** — verified by computation at both extremes (04:15 EDT in July, 03:15 EST in December). A cron cannot follow DST, so this is the only value that needs no edit at either switchover. Also confirmed while here: **`RENOVATE_TOKEN` now exists** as a repository Actions secret, so the workflow's fail-hard preflight will pass. It did not when #73 was authored. ## Still unresolved — the likelier remaining bug `renovate.json` lists `enabledManagers: [..., 'regex', ...]` and defines `customManagers` (the correct modern key; `regexManagers` is absent, which is right). But modern Renovate names the custom manager **`custom.regex`** in `enabledManagers`, not bare `regex`. If the bare name is ignored, **every inline `# renovate:` marker in the tree does nothing** — including the `external-snapshotter` `newTag` pin #73 flagged as probably inert. **Deliberately not changed**: guessing at a config key that could fail validation and take the whole run down is worse than a question one dry run answers. Dispatch with `dry_run: true` and `log_level: debug`, then look for a per-manager dependency-extraction count and any validation warning naming `regex`. ## Not verified - **Renovate has still never executed.** This fixes *when* it runs, not *whether it works*. - **A dry run outside the local window is less informative than it looks** — Renovate honours its schedule even in dry-run, so it will log "not within schedule" and show you nothing. Dispatch inside 03:00–06:00 New York, or override the schedule for that run. - **No alert fires if the schedule stops firing** — a disabled runner, expired token or deleted secret produces no signal at all. #73 recorded this gap; it is still open. - No conformance test asserts the cron falls inside `renovate.json`'s window, so this exact bug can return. 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-cron-window.md` 🤖 Generated with [Claude Code](https://claude.com/claude-code)

gitea-admin added 1 commit 2026-10-18 08:05:09 +00:00

fix(renovate): the cron fired outside Renovate's own window, so it would never open a PR

gate / gate (pull_request) Has been cancelled

Details

gate / conformance (pull_request) Has been cancelled

Details

095c48011d

.gitea/workflows/renovate.yaml shipped with `cron: "15 3 * * *"`. Gitea Actions
cron is UTC, and renovate.json carries schedule ["after 3am and before 6am"]
with timezone America/New_York -- and THAT inner schedule is authoritative:
Renovate re-checks it and declines to open PRs outside it.

  03:15 UTC  ->  23:15 EDT, the PREVIOUS EVENING in New York
  window     ->  03:00-06:00 local   =>  NOT INSIDE (3h45m early)

The original comment claimed the cron sat "slightly ahead" of the window. It
sat 3h45m behind it, on the previous day. Every nightly run would have started,
logged "not within schedule", opened ZERO PRs and exited SUCCESSFULLY -- a green
tick forever, indistinguishable from "nothing needed updating", hiding the ~30
pending updates PR #73 existed to surface.

Changed to `15 8 * * *`, chosen to survive DST rather than to look tidy:
  EDT (UTC-4): local 03:00-06:00 == 07:00-10:00 UTC
  EST (UTC-5): local 03:00-06:00 == 08:00-11:00 UTC
08:15 UTC is inside BOTH (04:15 EDT / 03:15 EST), verified by computation at
both extremes, so neither switchover needs an edit. A cron cannot follow DST.

Also confirmed while here: RENOVATE_TOKEN now exists as a repo Actions secret,
so the workflow's fail-hard preflight will pass.

STILL UNRESOLVED and the likelier remaining bug: renovate.json's
`enabledManagers` lists bare `regex`, where modern Renovate names the custom
manager `custom.regex`. If the bare name is ignored, every inline `# renovate:`
marker in the tree does nothing. Deliberately NOT changed -- guessing at a key
that could fail validation and take the whole run down is worse than a question
one dry run answers. See the handoff.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>

gitea-admin force-pushed fix/renovate-cron-window from 095c48011d to 0d4bd7297d

2026-10-18 08:12:30 +00:00

Compare

gitea-admin referenced this issue from a commit

2026-10-18 08:14:30 +00:00

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

gitea-admin referenced this pull request

2026-10-18 08:15:01 +00:00

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

jakman85 approved these changes

2026-10-18 08:18:32 +00:00

jakman85 merged commit 42ce001d71 into main