Problem: The release workflow warns when binaries exceed 5MB but does
not block the build. Since small binary size is a stated project goal
(release profile uses opt-level="z", LTO, strip, panic=abort), size
regressions can silently ship to users without any enforcement.
Solution: Convert the binary size check to a tiered gate:
- >5MB: emits a GitHub Actions warning (soft target, informational)
- >15MB: emits a GitHub Actions error and fails the build (hard limit)
- Adds a step summary with per-target binary size metrics for
visibility in the Actions UI.
The 15MB hard limit provides headroom for legitimate growth while
catching catastrophic regressions (e.g., debug symbols not stripped,
accidental fat dependency additions).
Testing: Validated YAML syntax. The shell script logic is
straightforward (stat + arithmetic comparison). The existing
unner.os != 'Windows' guard is preserved.
Ref: zeroclaw-labs/zeroclaw#618 (item 3 — Binary Size Gating)
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* ci(release): add concurrency group to prevent duplicate release builds
When two tags are pushed in quick succession, the release workflow could
run concurrently, producing corrupted or incomplete GitHub releases.
Add a concurrency group scoped to the tag ref so that release runs for
the same tag are serialized. cancel-in-progress is set to false to ensure
a running release completes rather than being aborted.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* ci(release): serialize all release runs globally
Use a constant workflow concurrency group so release publish jobs run one-at-a-time across tags, avoiding cross-tag race conditions.
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Will Sarg <12886992+willsarg@users.noreply.github.com>
The upload-artifact step in the release workflow had no retention-days
set, causing intermediate build artifacts to persist at the repository
default of 90 days and consuming storage unnecessarily.
Add retention-days: 7 since these are intermediate artifacts consumed
by the publish job in the same workflow run — they do not need
long-term retention.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The ubuntu-latest matrix entry had its target set to
'blacksmith-2vcpu-ubuntu-2404', which is a runner label — not a valid
Rust target triple. This causes 'cargo build --target' to fail or
produce artifacts for the wrong architecture.
Replace with 'x86_64-unknown-linux-gnu', the correct Rust target triple
for the ubuntu runner.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* chore(workflows): complete migration to Blacksmith cloud runners
Migrate remaining workflows from self-hosted axecap runners to Blacksmith:
- docker.yml: publish job
- release.yml: publish job
- security.yml: audit and deny jobs (conditional on push events)
This completes the transition away from self-hosted infrastructure.
Axecap runner registrations (IDs 21, 22) have been removed.
All workflows now use blacksmith-2vcpu-ubuntu-2404 label for consistency.
* Merge branch 'main' into selfhost-blacksmith
* ci: add SHA256 checksums to release artifacts
Generate a SHA256SUMS file after downloading all build artifacts and
include it in the GitHub Release. Users can verify download integrity
with `sha256sum -c SHA256SUMS`.
Closes#358
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
* ci: whitelist lxc-ci self-hosted runner label for actionlint
Add actionlint.yaml config to declare lxc-ci as a known custom label
for self-hosted runners, fixing the actionlint CI check.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Pin every third-party GitHub Action to its current commit SHA with a
version comment, eliminating supply chain risk from mutable version
tags. Mutable tags (v4, v2, etc.) can be force-pushed by upstream
maintainers; SHA digests are immutable.
18 unique actions pinned across 9 workflow files.
Closes#357
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>