The first release attempt failed at packaging:
cp: cannot stat 'target/aarch64-unknown-linux-gnu/release/runicgateway-installer':
No such file or directory
installer#10 added linux-aarch64 in three of the four places it belongs — the
rustup target, the `cp` into dist/, and the SHA256SUMS line — but never added a
build step for it. Nothing ever produced the binary, so the run got all the way
to packaging before noticing. No tag or release was created, so a retry is clean.
Two changes:
- Build arm64, with the same linker/CC/AR env pattern the Windows cross build
already uses.
- Name `libc6-dev-arm64-cross` in the apt install. gcc-aarch64-linux-gnu only
*recommends* it and this step runs --no-install-recommends, so without it the
Rust half builds and then `ring` (under ureq's rustls) dies compiling C on a
missing bits/libc-header-start.h.
Verified by reproducing CI in rust:1-slim-bookworm — the same apt line including
--no-install-recommends, then the same cargo invocation. Builds clean and emits
a 4.6 MB binary at exactly the path the packaging step reads.
Co-Authored-By: Claude <noreply@anthropic.com>
Brings main's publishing fixes onto edge so the cutover PR is a clean merge:
bundle.yml publishing to the `bundles` branch, release.yml going tag-only, and
the removal of bundles/*.json from main.
One conflict, resolved in favour of edge: main deleted bundles/bundle-2026.08.04.json
while edge had renamed it to tests/fixtures/published-bundle.json. Both changes say
the same thing — published bundles no longer live on main — so the fixture is kept.
It stays frozen at 2026.08.04 on purpose: it is the crate's test input, not a mirror
of what is currently published.
Co-Authored-By: Claude <noreply@anthropic.com>
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>
Step 4 of PLAN.md §5.2, and the half that faces the operator: the
release now cross-compiles aarch64-unknown-linux-gnu, and platform_key()
resolves ("linux","aarch64") to the bundle key link publishes under
instead of refusing the host by name.
Same toolchain shape as the Windows step -- a linker plus a CC/AR pair,
because ring (under ureq's rustls) compiles C and assembly. And the same
packaging trap named in the sums comment: an artifact missing from
SHA256SUMS is one `sha256sum -c` passes over silently, so the new binary
is added to both the sums and the upload list.
Two test changes fall out of the asset map growing a key:
- The exact `assets.len() == 2` assertion is replaced by a check that
each key CI requires is present and well-formed. An exact count would
fail on the first bundle that adds arm64 -- reporting correct
behaviour as a regression.
- The host-binary lookup now accepts either outcome, and says why.
Bundles are kept unchanged forever so `--bundle` stays reproducible,
which means one published before arm64 existed can never gain that
key. On such a host the run must fail with the reason rather than
something that reads like a corrupt document, so sidecar_asset()'s
error now says so and the test asserts it.
Verified by cross-building this crate for aarch64 in a
rust:1-slim-bookworm container -- ELF 64-bit LSB pie executable, ARM
aarch64 -- and by running fmt, clippy -D warnings and the tests on both
Linux and the Windows host, since only half of service.rs compiles on
either.
Co-Authored-By: Claude <noreply@anthropic.com>
Adds the Rust crate at the repo root and implements `install` end to end for
the overlay half of a deployment: resolve the published bundle, find and
validate the ServUO root, refuse to deploy under a running shard, sync the
plugin overlay, and record what was deployed in install.json.
`doctor`, `update` and `uninstall` parse and answer with the phase they arrive
in rather than "unrecognized command", and the run states plainly that the
uo-link sidecar (Phase 2) and the patch tier (Phase 3) were not installed —
`--patches` in particular reports REQUESTED BUT NOT APPLIED, since a quiet
completion would be read as a patched shard.
Landing on `edge` rather than `main`: release.yml publishes a binary on every
push to main, and an installer that deploys the overlay but cannot install the
sidecar is not something to hand an operator. pr-checks.yml now gates PRs into
edge on the same rules, so the branch the work happens on is not the ungated
one.
Notable decisions, all documented in docs/installer/PLAN.md §5 Phase 1:
- The code lives in a library called `rgdeploy` with a thin binary that keeps
the published name. Windows' UAC installer detection refuses to launch an
unsigned executable whose file name contains "install" (os error 740), and
Cargo names test harnesses after their target — so a target under that name
makes `cargo test` unrunnable on Windows.
- The running-shard check matches processes by path, not by process name:
on Linux a live shard is `mono`/`dotnet` with ServUO.exe as an argument, and
a name match would report "not running" for a shard that is running.
- install.json records a state (`deployed` / `kept-operator-modified`), not the
run's verb, so an unchanged re-run produces an identical record and writes
nothing.
- The Bridge.cfg keep rule compares against the hash the installer last
deployed, not the last hash it saw — otherwise a kept file is overwritten on
the very next run.
- Downloads are verified against the bundle's SHA256 while being written, then
every extracted file is re-hashed against the release's own manifest.json,
whose protocol and version are cross-checked against the bundle.
Verified against a real ServUO 57.4 tree and end to end into a scratch tree:
24 files deployed, an unchanged re-run that writes nothing, an edited
Bridge.cfg kept across repeated runs while code files are overwritten, bundle
pinning, and a refusal with a shard running out of the tree.
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>
