The same two faults link/release.yml has, in the copy this repo was
forked from -- and this one has never run at all, so the cutover would
have been its first execution.
An empty template expression written literally in a comment makes the
runner fail to build the "Commit version bump and push tag" step and
skip it WITHOUT failing the job. link carried that for six releases,
which is why its Cargo.toml still says 0.1.0 while its tags reach
v1.1.1; the tags exist because the release API creates one when it
publishes.
And the step pushes to main, which is protected -- the bundle job
proved that today with `pre-receive hook declined`. A first release
must not depend on a write to a protected branch.
So the tag is the version, as in servuo-plugins. The version is still
written into Cargo.toml before building, so a released binary
self-reports correctly; it is simply not committed back.
The prerequisites header said `main` must accept a direct push from the
CI user. It does not, and it should not; that line is replaced with the
reason.
Co-Authored-By: Claude <noreply@anthropic.com>
servuo-plugins hit both of these on its first real release run; this repo
runs the same engine, so it has the same two defects latent.
REGISTRY_USER / REGISTRY_TOKEN were empty there, yet the tag push
SUCCEEDED: actions/checkout leaves an `http.<host>.extraheader` credential
in the local git config, so `git remote set-url` to a URL with empty
credentials still authenticated through that leftover header. The release
API call had no such fallback and returned 401. Net result was the worst
available outcome — the repo tagged, no release, and a failed job.
Two fixes:
A credential preflight, before anything is built or pushed, gated on the
run actually intending to publish so a docs:/chore:-only merge (or this
repo's pre-crate no-op) still passes on a repo with no secrets. It names
the missing secrets and the scope they need instead of failing wherever
they happen to be used first.
Orphan-tag recovery. A tag with no release behind it means an earlier run
died after tagging, and the old code treated any existing tag as "nothing
to release" — so that state could never clear itself: every later run
would see the tag and stand down, forever. The plan step now asks the API
whether a release exists for the tag, and on 404 reuses the tag and
publishes the release it is missing. This deliberately overrides the
RELEASE=false the bump logic just decided, which is the whole point —
with the tag in place there are no releasable commits after it.
Anything other than 200/404 (network failure, bad token) is refused
rather than guessed, since assuming "no release" would republish over a
good one.
The tag step now reuses an existing tag instead of failing on `git tag`,
and the changelog for a recovery run summarizes what the tag contains
(previous-tag..this-tag) rather than the empty range after it.
sync-project-tree gets the same preflight: its first run on main failed
with an opaque `git clone` error against `https://:@host/...` that said
nothing about a missing secret.
Verified by extracting every run block and exercising the paths: empty
secrets fail the preflight with a legible message and populated ones pass;
the no-Cargo.toml guard still short-circuits to release=false; a crate with
no tag still takes the seed path; and against real repo state, a tag with a
release stands down while an orphan tag recovers.
Co-Authored-By: Claude <noreply@anthropic.com>
Bring this repo's CI up to parity with the other Runic Gateway repos. All
three are retargeted from RunicGateway/link, which is the closest analog
(same Rust toolchain, same release engine, same runner).
pr-checks.yml
Gates PRs into main on cargo fmt --check, clippy -D warnings, and
cargo test --locked, in that order, one job — mirroring release.yml's
gates so a green PR implies a green release.
release.yml
The conventional-commit release engine from link/, with the Rust
adapter retargeted: crate at the repo root, binary
runicgateway-installer, cross-compiled for x86_64 Linux and Windows.
Artifact names follow PLAN.md §3. The generated changelog now carries
the checksum-verification block, because releases are deliberately
unsigned and SHA256SUMS is the trust anchor (PLAN.md §3) — that makes
the verify instructions part of the release, not a doc someone has to
find.
sync-project-tree.yml (+ .gitea/scripts/gen_tree.py)
Regenerates docs/installer/PROJECT_TREE.md on every push to main and
opens or force-updates a PR against the docs repo. Verbatim from link/
apart from the repo/path/label env block.
Crate guard
This repo has no Cargo project yet — Phase 1 creates it. Landing the
workflows unguarded would red-X every governance and docs PR until
then, and holding them back leaves the repo ungated exactly while its
conventions are being set. So both Rust workflows check for a root
Cargo.toml first: pr-checks skips its gates with a notice, and
release.yml's plan step sets RELEASE=false and exits. Both arm
themselves the moment Cargo.toml lands, with no edit here.
Verified before pushing: all three files parse as YAML, every run block
passes bash -n, and the release plan step was simulated against a throwaway
git repo both without a crate (release=false, exit 0) and with one
(first-release path -> v0.1.0 with the changelog rendered).
Not included: the bundle-manifest workflow (PLAN.md §7) and the
release-dispatch hook, which are Phase 0 item 3 and depend on
servuo-plugins having a release workflow first.
Note for setup: release.yml and sync-project-tree.yml need REGISTRY_USER
and REGISTRY_TOKEN (write:repository, plus read/write on RunicGateway/docs)
configured for this repo.
Co-Authored-By: Claude <noreply@anthropic.com>
