This is the last stage of a three-stage release train — widgetii/majestic
publishes the majestic tarball, OpenIPC/firmware builds the images, this builds
from that tree. Each stage was its own GitHub cron sized against a guess at the
previous stage's runtime: 17:25, 22:30 and 03:00 UTC.
From 2026-08-26 GitHub began delivering scheduled events hours late and
independently per repo, and this repository was the worst affected of the three
— +10h38m and +11h49m on successive nights, a 03:00 slot sitting in the deepest
part of the congestion band. On the 08-28 cycle that made this stage run FIRST,
at 14:49, ahead of both the repositories it is supposed to follow. It went
green, as it always would: no stage checks that its inputs are newer than the
ones it used last time.
The delay is not ours and not fixable here: for every late run
`created_at == run_started_at` to the second, so all of it sits upstream of run
creation, inside GitHub's dispatcher. Moving the cron off the top of the hour
and pushing a commit to resync the schedule were both tried on the majestic
side; neither changed anything.
The ordering moves to the host that runs majestic's self-hosted runners, which
dispatches each stage in turn and waits for it to succeed before starting the
next.
Unlike majestic and firmware this needed no gate change, and the preflight
comment now says why: those two skip when nothing has changed and keyed that
skip on the event name, which a dispatch would have made unreachable. This one
deliberately always builds, so there was no event-name condition to go stale.
The clone guard rail keeps its logic and loses half its argument: an inherited
workflow can no longer run nightly and unattended on a stranger's Actions bill,
but it can still do so on every internal PR.
