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>
The installer repo was created empty. Seed it with the same governance set
every other Runic Gateway repo carries, so it starts on the same footing
before any Rust code lands (see docs/installer/PLAN.md for the design of
record — this repo is still in the planning phase).
Copied verbatim, byte-identical to the other repos:
LICENSE.md (GPL-3.0-or-later), CODE_OF_CONDUCT.md, CONTRIBUTORS.md,
.gitea/PULL_REQUEST_TEMPLATE.md, .gitea/ISSUE_TEMPLATE/{bug_report,
feature_request}.md
Repo-specific:
README.md what the installer is, what it deliberately is not
(no curl|bash, never writes a ServUO launcher), the
planned commands, and the constraints a reader needs
up front: unsigned releases, bundle-manifest
composition, opt-in patch tier, and the fact that a
successful copy is not a working bridge.
CONTRIBUTING.md adapted from link/ (same Rust toolchain and checks),
plus a planning-status note pointing changes of scope
at the plan in docs/, and the two shard-testing traps.
SECURITY.md adds the installer to the component scope table and a
short subsection on its distinct trust model: unsigned
releases anchored on SHA256SUMS, mandatory
verification of downloaded artifacts, and the
never-contacts-the-website token handoff. This is the
only file that now differs from the other repos' copies.
.gitignore Rust build output plus local deployment state
(install.json, sidecar.toml, *.db) that must never be
committed from a test run.
.gitea/ISSUE_TEMPLATE/config.yaml same as elsewhere, repo-local URL.
No CI workflows yet — there is no crate for pr-checks to build, and the
release/bundle workflows are Phase 0 work that depends on servuo-plugins
gaining a release workflow first.
Co-Authored-By: Claude <noreply@anthropic.com>
