wtclaude
07021d38c9
An existing tag was treated as "nothing to release", unconditionally. That is wrong in the one case it matters: a tag with no release behind it means an earlier run tagged and then died before publishing -- which is exactly what happened on servuo-plugins' first release, where absent REGISTRY_* secrets took the release API call to 401 after the tag had been pushed. Standing down on the tag alone makes that permanent. Every later run sees the tag, sets RELEASE=false, and the release never appears; the version is unpublishable forever. The tag now decides nothing on its own. The API does: 200 -> a release exists, stand down 404 -> tag without release, reuse the tag and publish what is missing else -> refuse and exit 1 The last arm matters as much as the others. A 000 from a network failure or a 401 from a bad token is not evidence of absence, and guessing "no release" would republish over a good one. Note the 404 arm deliberately overrides the RELEASE=false decided just above it: with the tag in place there are no releasable commits after it, so the normal path always stands down -- which is why this could never self-heal on its own. Two consequences handled with it. The changelog range is now previous-tag..this-tag on a recovery run, since a run finishing an earlier one has nothing after the tag and would otherwise publish an empty change list. And the tagging step tolerates the tag already existing, because `git tag` on an existing name fails under `set -e` while pushing an identical tag is a harmless no-op -- a push that does fail there means the remote tag points somewhere else, which should stop the run. This is the same handling installer/release.yml already carries; link was the copy that still had the trap. Verified by extracting this step and driving it through four scenarios against a real clone with the live tags, with curl stubbed to return each status: a normal patch bump (v1.1.1, release=true), a tag with no release (recovers, release=true), a tag with a release (stands down), and an unreachable API (exit 1, publishes nothing). Co-Authored-By: Claude <noreply@anthropic.com>
uo-link — Rust sidecar
The Rust sidecar half of the Runic Gateway bridge. The ServUO shard dials out to this sidecar over a loopback TCP socket (newline-delimited JSON); the sidecar owns the WebSocket + REST API the website consumes, along with auth, buffering, and fan-out.
ServUO plugin (C#, net48) ──loopback TCP, newline-JSON──► Rust sidecar ──WebSocket/JSON──► website
(RunicGateway/servuo-plugins) >>> THIS REPO <<<
The shard never speaks WebSocket and exposes no port of its own — the sidecar is the only network-facing component, which is what keeps the game unreachable from the internet.
Related repos
| Repo | What |
|---|---|
this — RunicGateway/link |
The Rust sidecar (sidecar/). |
| RunicGateway/servuo-plugins | The C# ServUO plugin — the shard side of the bridge (overlay/, patches/, deploy.ps1, test scaffolding). |
| RunicGateway/docs | All project documentation — design docs, protocol spec, integration guide, research. |
Layout
| Path | What |
|---|---|
sidecar/ |
The Rust sidecar crate — terminates the loopback link to the shard, exposes WS + REST to the website. See sidecar/README.md. |
.gitea/workflows/pr-checks.yml |
Gates every PR into main on cargo fmt --check, cargo clippy -D warnings, and cargo test. |
.gitea/workflows/release.yml |
Builds + releases the sidecar binary (Linux + Windows) on every merge to main. |
Build & run
The sidecar is a standard cargo crate:
cd sidecar
cargo build --release # binary at target/release/uo-link-sidecar
cp sidecar.toml.example sidecar.toml # then edit
cargo run --release
Deploying it rather than developing on it: --config <PATH> names the config file (as does
$UOLINK_CONFIG), and --print-config prints the resolved settings — including the auth token
the website needs — as JSON, provisioning the config file on first run. That is the supported way
to read the token back; it is not meant to be scraped from the log.
uo-link-sidecar --print-config --config /etc/runicgateway/sidecar.toml
.gitea/workflows/release.yml cross-compiles Linux + Windows binaries and cuts a Gitea release on
every merge to main (conventional-commit versioning). See sidecar/README.md
for configuration and the wire protocol.
Before that, .gitea/workflows/pr-checks.yml runs the same gates on every pull request into main —
cargo fmt --check, cargo clippy --all-targets -- -D warnings, then cargo test --locked. Run them
locally before pushing and the PR will be green:
cd sidecar
cargo fmt # or --check to just report
cargo clippy --locked --all-targets -- -D warnings
cargo test --locked
Deployment & compatibility
The plugin (RunicGateway/servuo-plugins) and this sidecar are deployed together but built independently:
- The plugin is deployed as source into the ServUO server root and compiled by ServUO at boot — no build artifact, no CI build.
- The sidecar is a standalone Rust binary released from this repo.
The only coupling is the loopback JSON protocol (the shard dials 127.0.0.1). Compatibility is a
protocol concern, not a build-order one — keep the event/command catalog in sync across the two
repos. Canonical spec:
PLAN.md §5/§7 and
INTEGRATION.md.
Because a wedged or absent sidecar cannot stall the shard, either side can be deployed or restarted
independently.
License
Runic Gateway is free software, licensed under the GNU General Public License v3.0 or later — see LICENSE.md.
Copyright (C) 2026 Runic Gateway
This program is free software: you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free Software
Foundation, either version 3 of the License, or (at your option) any later
version. It is distributed WITHOUT ANY WARRANTY; without even the implied
warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
Contributions are welcome — please read CONTRIBUTING.md (note the AI-usage disclosure requirement) and our Code of Conduct. Report vulnerabilities privately per SECURITY.md.