Module-rust phase 18, step 2 of docs/modules/rust/PLAN.md §34.2.7 (D146,
D147). The compose job now writes three streams on the bundles branch:
current.json schema 1, ServUO, exactly as before
v2/servuo/ schema 2, game "servuo"
v2/rust/ schema 2, game "rust" (Rust-Link + Rust-Plugins)
The gates move into .gitea/scripts/compose-bundles.sh, so they can be run by
hand against the real release API or a mock without a runner. Each game
composes independently: a Rust failure still lets a ServUO bundle publish, and
the run goes red afterwards. A game whose repos have never released composes
nothing and does not fail, which is where Rust is until its cutover.
A ServUO matrix carries the same tag at both schemas, so the first run
publishes v2/servuo/bundle-2026.09.15.json rather than a second name for the
pair. Schema 1 stops being composed on 2027-01-01 and is left frozen.
Tested in debian:12 against the real releases (v2/servuo published as
2026.09.15, schema 1 unchanged, Rust skipped; rerun is a no-op; past the
retirement date schema 1 is frozen) and against a mock Gitea for Rust
(document composed, protocol mismatch refused, missing manifest key refused,
rerun a no-op, ServUO failing independently).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
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>
