Routes the release build/test steps and a new fast pre-release
check.yml through ci/build.sh, which delegates to bread-ecosystem's
pinned shared Containerfile/build.sh instead of building against
whatever the bare hestia runner happens to have installed. Follows
the pattern already proven in breadpad. No extra ci/deps.txt: bread's
system_deps (systemd-libs, openssl, zlib) are all already pulled in
transitively by the shared image's base + git packages.
Two remaining pieces from the original report, both explicitly signed
off on:
1. Wire cargo run -p xtask -- check-docs into dev-release.yml as a
fail-fast step ahead of the release build/test, so drift between
api-schema.toml and the real API surface now fails CI instead of
relying on local discipline.
2. Extend api-schema.toml and check-docs to cover the bread CLI's
command surface (bread-cli/src/main.rs's Commands/ModulesCommand/
HooksCommand enums) against README.md's "CLI reference" section,
not just Lua bindings/IPC methods against Documentation.md. This
was the specific blind spot that let modules audit, hooks
install-shell/install-git, and events --tree drift out of README
in the first place -- check-docs would not have caught that fix
without this extension, since its prior scope never touched the
CLI-vs-README relationship at all.
Extraction reuses the same deliberate-textual-scanning approach as
the existing Lua/IPC extractors: depth-tracked enum variant scanning,
clap's PascalCase->kebab-case rename convention, and a hardcoded
(TABLE_VARS-style) map of which top-level Commands variants delegate
to a nested subcommand enum (Modules->ModulesCommand,
Hooks->HooksCommand), producing dotted names like modules.audit.
CLI commands are versioned against the package version (Cargo.toml),
not API_VERSION, since the CLI was never part of that versioned
contract -- documented in api-schema.toml's header.
Verified check-docs actually catches CLI/README drift, not just
passes: temporarily deleted the "bread modules audit" line from
README.md, confirmed check-docs failed with the exact right message,
restored it. 4 new unit tests cover the extraction and cross-check
logic (11 total in xtask, up from 7).
Replaces the dev/beta branch split with one trunk (main): dev-track
builds still publish on every push, but the beta track now publishes
from a vX.Y.Z-rc.N prerelease tag instead of a separately-maintained
beta branch. Removes the branch nobody reliably kept in sync.
bakery already fully covers what the PKGBUILD provided (binary, systemd
--user service where applicable, dependency declarations) except a LICENSE
copy, which bakery.toml's new license_file field now closes. Removes
packaging/arch/ and .forgejo/workflows/package.yml; adds the LICENSE
artifact to each release/dev-release/beta-release workflow's prepare
step. Not pacman-installed inside BOS today (BOS already consumes these
apps exclusively via build-local.sh's skel-staging), so this only removes
the option to `pacman -S` outside of BOS/bakery.
Beta is now a real stabilization branch: publishes on every push to
`beta` (mirroring dev's model, auto-versioned X.Y.Z-beta.<ts>+<sha>,
base version from the latest published tag) instead of a manual
beta-v* tag. Fixes made during the freeze land via fix/<issue> branches
merged into `beta` directly. The gen-index.sh clone for beta pulls
bread-ecosystem's default branch (main) rather than pinning to dev,
since beta is the more stable track and main now carries the
TRACK-aware script.
Cargo.toml can drift stale relative to the actual last release (observed
on breadbox/breadpad/breadcrumbs/breadpaper), which made the auto-bumped
dev version sort as OLDER than what's already installed — bakery's semver
check correctly refused those "updates". Deriving the base version from
git ls-remote --tags instead is self-healing regardless of Cargo.toml
drift, with a Cargo.toml fallback only for a repo with no tags yet.
The fixed /tmp/bread-ecosystem-ci path races when multiple repos' dev/beta
workflows run close together on the same self-hosted runner — one job's
rm -rf/clone can stomp another's in-progress checkout, causing the
regenerate-index step to fail intermittently. Switch to mktemp -d.
The TRACK-aware gen-index.sh only exists on bread-ecosystem's dev branch
so far (not yet merged to main). Without --branch dev, the remote clone
defaulted to main and silently ran the old track-blind script, which is
why dl.breadway.dev/dev/index.json never actually picked up bread's dev
builds despite the workflow reporting success.
The remote gen-index.sh call never had MINISIGN_SEC_KEY wired through, so a
missing/misconfigured secret silently produced an unsigned index.json that
overwrote the previously-signed one instead of failing the job — this is
why bread's dev track never appeared in dl.breadway.dev/dev/index.json
after the first dev-release.yml run despite it reporting success.
Mirrors the new stable/beta/dev track feature landing in bread-ecosystem's
bakery. dev-release.yml publishes on every push to dev; beta-release.yml
publishes on a beta-v* tag. Both skip the GitHub Release upload step and
publish to dl.breadway.dev/{dev,beta}/bread/ via gen-index.sh's new TRACK
env var. See bread-ecosystem/docs/release-channels.md for the full policy.
GitHub Actions self-hosted runners need per-repo registration on a
personal account; Forgejo Actions' runner already serves every repo
with zero setup. Moves release publishing there (dl.breadway.dev stays
the primary bakery target; GitHub release upload is kept as the
fallback via an explicit token, since Forgejo Actions has no ambient
GITHUB_TOKEN) and adds a mirror workflow to keep GitHub in sync
automatically.
- .forgejo/workflows/mirror.yml: mirrors every push/tag to GitHub
- .forgejo/workflows/package.yml: builds PKGBUILD on tag and publishes
the bread package to the Forgejo Arch registry (distrib=breadway)
Requires two Forgejo secrets:
GITHUB_MIRROR_TOKEN — GitHub PAT with repo push scope
FORGEJO_TOKEN — Forgejo token with package:write scope
