ci: add a manual publish workflow (crates.io, idempotent + expandable)
A workflow_dispatch publish.yaml (mirrors release-macos.yaml) with a `tag` input, run by hand once the automated release builds exist. Publishing stays manual and keeps the registry token off every tag push: it's irreversible (yank-only), the split release (tag Linux/Windows + dispatched macOS) makes a human the 'all assets up' gate, and crates.io has no Gitea-Actions trusted-publishing path. The crates.io job is idempotent (crates.io API pre-check + cargo publish as backstop) and independent (no inter-job needs), so future Scoop/Homebrew/winget jobs can be added alongside without interfering or breaking re-runs. Token via the CARGO_REGISTRY_TOKEN secret. ADR-0056 Amendment 1 + README index also record 0.2.0 published + binstall verified.
This commit is contained in:
@@ -86,3 +86,27 @@ verified against cargo-binstall SUPPORT.md):
|
||||
- Remaining follow-up: run the real `cargo binstall` validation at the
|
||||
first publish + matching release (the license files, © holder, and
|
||||
CONTRIBUTING are now in place).
|
||||
|
||||
## Amendment 1 — 2026-06-18: published live + a manual `publish` workflow
|
||||
|
||||
**`rdbms-playground 0.2.0` is published to crates.io** (`cargo install` and
|
||||
`cargo binstall rdbms-playground` both verified working by the user). The
|
||||
"unverified binstall" caveat is resolved — the per-target overrides
|
||||
resolve correctly against the `v0.2.0` release assets.
|
||||
|
||||
**How publishing is wired:** a new **manual `workflow_dispatch` workflow**
|
||||
(`.gitea/workflows/publish.yaml`), mirroring `release-macos.yaml`, takes a
|
||||
`tag` input and runs `cargo publish` (token via the
|
||||
`CARGO_REGISTRY_TOKEN` Gitea Actions secret — a crate-scoped,
|
||||
publish-update token). **Not** automated on the tag, by decision: the
|
||||
publish is irreversible (yank-only), keeping the registry token off every
|
||||
tag push; the release is split (Linux/Windows on the tag, macOS
|
||||
dispatched), so a human is the natural "all assets are up — go" gate; and
|
||||
crates.io has no Gitea-Actions trusted-publishing path today, so a stored
|
||||
token on the self-hosted runner would be the only automated option.
|
||||
Each registry is its **own idempotent job** (no inter-job `needs`) — the
|
||||
crates.io job skips cleanly if the version is already published (crates.io
|
||||
API pre-check + `cargo publish` as the backstop) — so future
|
||||
Scoop/Homebrew/winget jobs can be added alongside without breaking one
|
||||
another or re-runs. The first such job's `tag`-vs-`Cargo.toml` guard
|
||||
mirrors `release.yaml`.
|
||||
|
||||
Reference in New Issue
Block a user