* ci: write releases from one paced job, not from 107 at once
Every matrix job uploaded its images to three shared releases with
softprops/action-gh-release, so a nightly fired on the order of 400
concurrent asset writes at `nightly`, `latest` and the dated tag.
OpenIPC/firmware ran exactly this design and the releases API answered
HTTP 500 under the contention -- run 27108181857 built every board and
still went red on 14 jobs, all of them in their upload step. Firmware
then hit the sequel: consolidating into one job but keeping concurrent
uploads tripped the per-actor secondary rate limit at 350 of 393 assets.
This lands where that ended up, without the two failures in between.
Matrix jobs now stage what they produced into dist/ and hand it to
actions/upload-artifact. A single publish job downloads all of it and
drives the release writes with gh: one asset at a time, paced ~1/s under
the per-minute mutation ceiling, with exponential backoff so a transient
403/429 is retried rather than failing the nightly. The single-writer
property is what fixes the 500s; the pacing is what keeps the fix from
tripping the other limit.
The dated release keeps the full asset set, because enrich_manifest.py
only ever reads dated releases. `nightly` and `latest` are delivery
aliases for flashers and now get images only: re-uploading the size
sidecars to two more tags is pure rate-limit cost, and nothing reads
them from those tags.
Staging copies whichever of the two naming schemes the build used --
compound devices rename to <device>-<flash>.tgz in the workspace root,
single-underscore ones leave openipc.<soc>-<flash>-<variant>.tgz under
openipc/output/images/ -- so asset names are byte-identical to today.
Checked both against enrich_manifest.py's COMPOUND_RE and SIMPLE_RE.
ci-gate covers publish, so a failed release write fails the run instead
of passing quietly.
The staging loop uses `if` rather than a trailing `&&` chain: the step
runs under `bash -e`, where a chain that tests false is only harmless
because something after it happens to reset the status.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
* ci: stop the publish job succeeding without publishing
Two High findings on #121, both real.
The download step carried continue-on-error: true, so a transient or real
artifact-download failure produced an empty dist/, the publish step's
count guard skipped it, the job went green, and ci-gate accepts
publish=success. A nightly could silently write nothing while the run
stayed green.
The flag stays -- it exists so a matrix where every device failed, and
so uploaded no fw-* artifact at all, does not hard-fail before the gate
can report why -- but Collect now turns it back into a failure for every
other case: if the matrix went green, a download that did not succeed is
an error, and zero collected assets is an error. Only "matrix failed and
produced nothing" is still tolerated, and the gate fails that run on the
matrix result anyway.
The second finding said count could read " 0" because wc pads. On
GNU coreutils, which is what the runner has, it does not -- that is BSD
behaviour, and `printf '' | wc -l` here gives an unpadded 0. Normalised
anyway, since it costs a tr and stops the guard depending on which wc is
in front of it.
Chasing it did surface a worse hole it sits next to. dist/ can hold
sidecars and no images -- one device that produced a size report and no
.tgz is enough -- and count is then 1, so publish ran, force-moved the
nightly and latest tag refs, and uploaded zero images. The two tags users
flash from would point at a build with no firmware behind them. Both tags
now move only when there is at least one image to move them to;
otherwise they stay on yesterday's, with a warning.
Checked all four states offline, since none of this path can run on a
pull request: green matrix with a broken download, green matrix with an
empty dist, failed matrix with nothing produced, and a normal night. The
first two now fail and used to pass.
Note the same continue-on-error and unnormalised wc are in
OpenIPC/firmware's publish job, which is where this one came from.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
