Commit graph

4 commits

Author SHA1 Message Date
Sirius DevOps
ef78be4035
fix(release): refuse to publish 0-byte assets + log on-disk sizes
Some checks failed
ci / test (push) Has been cancelled
Run 309 reported success but uploaded 0 bytes for both aarch64 assets
(a 0.85s 'upload' of an 18MB file). The Pack step had just listed
18258736 bytes and sha256sum -c'd OK, so the failure is in the handoff,
not the build.

- publish-release.sh now fails loudly on a 0-byte asset instead of
  publishing a release that silently breaks every download
- the workflow logs pwd, GITHUB_WORKSPACE, ls -l dist/ and the byte count
  of each dist file immediately before publishing

Ruled out: the api_curl retry wrapper. Reproduced from inside a
node:20-bullseye container (curl 7.74, same as CI) — wrapper and plain
curl both uploaded 994 bytes correctly through Cloudflare.
2026-09-10 14:20:45 -04:00
Sirius DevOps
cbbf3f6baa
fix(release): harden publish curl against Cloudflare HTTP/2 stream errors
All checks were successful
ci / test (push) Successful in 6m1s
The dispatched v0.1.1 build succeeded a third time (2m06s, valid ARM ELF)
and then died at the first API call inside the publish step with curl exit
92 (HTTP/2 stream error) — job containers reach Forgejo through Cloudflare,
where that is intermittent.

- all API calls go through api_curl: --http1.1 --retry 5
  --retry-all-errors --retry-delay 3 --connect-timeout 20 --max-time 300
- HTTP/1.1 is the documented workaround for this instance's HTTP/2 resets

Job containers cannot reach http://forgejo:3000 (isolated GITEA-ACTIONS
network, name unresolvable, container IP unroutable — measured), so the
public hostname plus retries is the available fix.

Verified locally: create + idempotent re-run against a throwaway tag, both
clean; test release and tag deleted.
2026-09-10 14:08:39 -04:00
Sirius DevOps
9441bccf58
fix(release): tooling checkout so old tags can publish; never move a tag
Some checks failed
ci / test (push) Successful in 5m46s
release / aarch64 (push) Failing after 5m46s
The dispatched build of v0.1.1 kept failing at publish with
'scripts/publish-release.sh: No such file or directory' — the workflow is
read from the dispatch ref (main) but the workspace was the v0.1.1 tag,
whose tree predates scripts/ and .forgejo/.

- second checkout of the workflow's own ref into .ci-tools; publish runs
  .ci-tools/scripts/publish-release.sh (and .ci-tools/scripts/release-body.md)
- exclude ./.ci-tools from the build context tar
- target_commitish is now opt-in in publish-release.sh and only set for a
  push event, so a re-publish can never move an existing tag

Verified locally end-to-end against a throwaway tag: create, idempotent
re-run (stale assets deleted + replaced), public download, sha256sum -c,
--version. Test release and tag deleted afterwards.
2026-09-10 13:58:46 -04:00
Sirius DevOps
91fd9601b8
ci: Forgejo-native ci + release workflows
Some checks failed
ci / test (push) Failing after 1m6s
The GitHub workflows could never run on this instance: jobs asked for
ubuntu-24.04 runners (the Pi runner only registers the 'docker' label, so
every job sat in waiting), and release.yml published to github.com, which
is not a remote of this repo.

- .forgejo/workflows/ci.yml  — cargo test + clippy on the 'docker' label,
  Rust work in a rust:1.87-bookworm sibling container (aarch64 native)
- .forgejo/workflows/release.yml — on v*.*.* tags, build aarch64, strip,
  sha256, publish to the Forgejo release; workflow_dispatch takes a tag
  to re-publish
- scripts/publish-release.sh — idempotent create-or-update release +
  asset upload via the Forgejo API (replaces same-named assets)
- scripts/build-release-local.sh — x86_64 path (no x86_64 runner exists)
- scripts/release-body.md — release notes template (@TAG@ substituted)
- README: install URLs -> Forgejo, accurate maintainer release procedure
- remove .github/workflows/*
2026-09-10 13:10:56 -04:00