This file is the ancestor of installer's release.yml, and installer#22's
release run found two gaps in it the hard way: the run built every artifact,
pushed its tag, then took a 500 from POST /releases one second later and exited
22, leaving the tag orphaned with no binaries published.
link has not hit that, but it has the same two gaps verbatim.
`curl -sSf` prints no response body on an error status, so the only thing such
a failure leaves in the log is "curl: (22) ... error: 500" and the cause has to
be inferred from timestamps. Every call in the release step now captures the
body and prints it on failure, including the asset uploads.
And nothing retried, so a transient 5xx becomes a permanent orphan. The POST
now retries five times with a 5/10/15/20s backoff. 4xx is deliberately not
retried: a bad token or a malformed body will not improve by being sent again,
and retrying would turn a clear failure into a slow one.
The asset uploads get the same treatment, because a release whose SHA256SUMS
does not cover every binary it advertises is worse than no release -- that file
is the trust anchor for an unsigned download.
The third gap is the one worth reading. The orphan-tag recovery in the plan
step is VERSION-SCOPED: it computes VERSION from the newest tag plus the bump,
then only checks refs/tags/v${VERSION}. That recovers an orphan on the very
next run and is useless afterwards, because once any releasable commit lands
the next run computes a NEW version and never looks at the old tag again.
servuo-plugins v0.1.0 proves it, and the proof is pointed: the commit that
ADDED that recovery was itself typed "fix(release): ... recover the orphaned
v0.1.0 tag", so it bumped to v0.1.1 and the run that introduced the recovery
stepped straight past the tag it was written to rescue. That tag is orphaned to
this day.
So the plan step now sweeps every v* tag and warns about any without a release.
Deliberately warns rather than recovers: publishing an old version would mean
building today's tree and shipping it under a tag whose tree it is not, which
is worse than the inconsistency it fixes. It also never fails the run -- a
sweep that can break a good release is a sweep someone will delete.
Verified by extracting both steps from the YAML and running them: bash -n
clean, the YAML parses, no empty template token in either step, the retry loop
exercised against a stubbed curl across seven cases (first-try success,
500-then-success, two 500s then success, five 500s giving up, 403 and 404
aborting without retrying, and a 000 network failure retried), and the sweep
run against the real repositories -- link clean, servuo-plugins reporting
v0.1.0, installer clean.
Typed ci(...) rather than fix(...) on purpose: the plan step bumps on feat/fix,
and this changes no binary, so a release here would be an empty one. That is
the same rule the fix commit above tripped over.
Co-Authored-By: Claude <noreply@anthropic.com>
Protocol 4 gives the guild board a real member list instead of the member
*count* that was all Protocol 2 could express. `guild.roster` carries the set;
`guild.leave` is forwarded but deliberately not projected.
The roster lives in its own `members` column rather than as a field folded into
`json`. That column holds the verbatim `guild.update` line, so a roster write
into it would clobber the snapshot — name, abbreviation, leader, online count —
that `guild.update` owns. Two writers across two columns of one row means both
stay plain upserts: neither reads the other's value first, so there is no
read-modify-write and no ordering requirement between the two kinds. `GET
/guilds` folds the roster back in as `roster` at read time.
`guild.leave` gets no board arm on purpose. The shard re-emits `guild.roster`
whenever the member set changes, so the board self-corrects within one sweep,
and keeping the delta out of the projection is what keeps the sidecar a
forwarder rather than a thing that maintains state.
This is also the repo's first store migration, and the reason it needed one:
`SCHEMA` is `CREATE TABLE IF NOT EXISTS`, which can add a table but cannot add a
column to a table that already exists. Every schema change up to and including
Protocol 3.0 happened to add whole tables, so `ALTER TABLE` appears nowhere in
this repo's history and the gap was invisible. `guilds.members` is the first
column added to an existing table, so without a mechanism the column would
simply never reach an installed sidecar and every roster write would fail.
The counter is SQLite's own `PRAGMA user_version` — an integer in the database
header, so it costs no table and cannot drift from the file it describes. Each
step runs in a transaction together with the bump recording it, so a step lands
completely or not at all. A database written by a *newer* sidecar warns and
continues rather than failing: every step is additive, so a newer schema has only
columns an older reader ignores, and refusing to start would turn rolling the
binary back — a recovery path — into a dead end.
A migration failure aborts startup, which was already the behaviour and is the
right one: a half-migrated store answers the website with confusing partial data,
and the shard dials *out*, so a sidecar that refuses to start never stalls the
game.
store.rs had no tests before this. The six added here cover the upgrade path that
matters (an existing pre-Protocol-4 database gains the column and lands at the
current version), that a restart re-running the migration is a no-op, that a
roster does not clobber the snapshot, that the two writers work in either order,
and that a guild with no roster yet has no `roster` key at all — "not known" and
"known to be empty" must not be conflated, or a website renders an empty roster
as fact.
Also gates PRs into `edge`, not just `main`. This workstream lands ten phases
there, and gating only the `main` hop would run these checks for the first time
at the cutover. The precedent and the reasoning are already in
RunicGateway/installer's copy of this workflow.
Refs: docs/website/TEAMS.md Part 12 Phase 1
Co-Authored-By: Claude <noreply@anthropic.com>
The "Commit version bump and push tag" step had two problems, and the
first hid the second.
It has never once executed. An empty template expression written
literally in one of its comments makes the runner fail to build the
step's script, and a step it cannot build is skipped WITHOUT failing
the job. That is why sidecar/Cargo.toml still says 0.1.0 after six
releases, and why the tag-reuse handling added in #27 was dead on
arrival. The tags exist because Gitea's release API creates one when it
publishes -- the pipeline has been working by accident.
And had it executed, it would have been declined: main is protected, so
the push is rejected by the pre-receive hook. The installer's bundle job
hit exactly that today. A release must not depend on a write to a
protected branch.
So the tag is the version, as it already is in servuo-plugins, whose
release workflow was written this way on purpose and has never needed a
protection exception. The workflow still writes the real version into
Cargo.toml before building, so a released binary self-reports
correctly; what it no longer does is commit that edit back. Nothing
downstream reads the file -- the next version is computed from the
newest tag.
The comment is reworded so the step can actually run, and warns against
writing that token in a comment again. No literal occurrence is left in
this file.
Co-Authored-By: Claude <noreply@anthropic.com>
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>
Step 2 of installer PLAN.md §5.2. The shard dials the sidecar out on
loopback, so wherever ServUO runs this binary has to run too -- and
Ampere/Graviton instances and Pi-class boxes are a realistic ServUO
home. Until now the release cross-compiled x86_64 Linux and Windows
only, so the installer refused every arm64 host by name.
Cross-compiling this crate is not Rust-only: sqlx's sqlite feature
pulls libsqlite3-sys, which compiles bundled SQLite from C. The build
therefore needs a CC/AR pair as well as a linker, the same shape the
Windows step already has.
libc6-dev-arm64-cross is named explicitly because gcc-aarch64-linux-gnu
only recommends it and this install passes --no-install-recommends: with
the compiler alone, SQLite's build dies on
/usr/include/stdio.h:27: fatal error: bits/libc-header-start.h
Both the failure and the fix were reproduced in a rust:1-slim-bookworm
container against this crate before the workflow was written.
The new binary is added to SHA256SUMS and to the upload list. Every
artifact has to appear in both: the installer verifies its download
against those sums, and `sha256sum -c` passes silently over a file the
sums list does not mention.
Merge order matters -- installer#9 teaches the bundle CI this asset
name, and must land first. An unrecognized link asset is a hard failure
there, by design, so a release published before it would redden the
compose job.
Co-Authored-By: Claude <noreply@anthropic.com>
Phase 0 item 3 of docs/installer/PLAN.md wired up from this side. The installer
does not resolve "latest" at run time — it installs the exact combination named
by a published bundle manifest (PLAN.md §7.1), so until now a new sidecar release
was invisible to operators until the installer repo's nightly cron noticed it.
Adds a final step that POSTs to RunicGateway/installer's bundle workflow-dispatch
endpoint. The bundle job re-reads PROTOCOL_VERSION from sidecar/src/main.rs at the new
release tag and checks it against the overlay's declared protocol before
publishing anything (gate 1), so a bump that lands without its plugin half is
caught at compose time instead of on an operator's shard.
Dispatch, don't wait (PLAN.md §7.3): Gitea's dispatch endpoint returns no run
handle, so there is nothing to poll — a waiting step would have to guess which
run is its own while holding a runner idle. The bundle job runs its own gates
regardless of who started it.
A dispatch failure is a warning, never a failure of this job. By the time this
step runs the release is published and correct, so failing the run would
misreport that; the installer's nightly cron recomposes from whatever the latest
releases actually are, making a dropped dispatch cost latency rather than
correctness. That also means REGISTRY_TOKEN having write on the installer repo
is a nicety, not a new hard requirement — noted in the header.
Verified the workflow still parses and that the new step is last, gated on
release=='true', and contains no path that can exit non-zero.
Co-Authored-By: Claude <noreply@anthropic.com>
This repo had no pull_request workflow at all — release.yml runs only
after merge, so its `cargo fmt --check` gate was the first thing to see
new code, and an unformatted commit killed the release job before it
could build, tag, or publish (run for 2301c57).
Add pr-checks.yml, mirroring release.yml's gates in the same order so a
green PR implies the release clears its own gates:
cargo fmt --check
cargo clippy --locked --all-targets -- -D warnings
cargo test --locked
One job, not three: bootstrapping the toolchain costs more than the
checks, so parallel jobs would pay it three times for no wall-clock win.
Cargo registry and target/ are cached on Cargo.lock. The crate is
already clean at `-D warnings`, so clippy starts green.
Co-Authored-By: Claude <noreply@anthropic.com>
Add a sync-project-tree workflow that regenerates this repo's tracked-file
tree and opens (or force-updates) a PR against RunicGateway/docs whenever the
layout on main changes. Never writes to the docs repo's main directly. Reuses
the existing REGISTRY_USER / REGISTRY_TOKEN secrets. Tree rendering lives in
.gitea/scripts/gen_tree.py (deterministic, dirs-first ordering).
Co-Authored-By: Claude <noreply@anthropic.com>
The SonarQube server already has a project keyed Runic-Gateway-link and
refuses to create a case-variant duplicate, so the scan (added in #13)
failed to auto-create runic-gateway-link. Match the existing key.
Co-Authored-By: Claude <noreply@anthropic.com>
Mirrors the website repo's setup: a source-based scan of sidecar/src that
reports to the self-hosted SonarQube server after merge, never gating PRs.
Co-Authored-By: Claude <noreply@anthropic.com>
Repo was transferred UOM -> RunicGateway. The REPO env var drives both
the git push URL (bump commit + tag) and the release API base, so the
release workflow would otherwise still target the old UOM/link path.
The release run built its push URL and auth header directly from
`secrets.REGISTRY_USER` / `REGISTRY_TOKEN`. A trailing newline in
REGISTRY_USER produced a malformed remote:
warning: url contains a newline in its username component
fatal: credential url cannot be parsed
Pass the secrets through `env:` and strip CR/LF (`tr -d '\r\n'`) before
building the URL (push step) and the `Authorization: token` header (release
step). Using env instead of inline `${{ }}` also stops a newline from
breaking the shell script itself. Verified the file still parses and the
trim turns `Whitlocktech\n` into a clean single-line URL.
Underlying cause is secret hygiene (the value was saved with a trailing
newline); this makes the workflow robust to it either way.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0114TpmrNW4wNXsHq5CR72jQ
The release step rewrites the crate version in Cargo.toml (0.1.0 -> next),
which desyncs this crate's own entry in Cargo.lock. The following
`cargo test/build --locked` steps then abort:
error: cannot update the lock file ... because --locked was passed
Run `cargo update --manifest-path sidecar/Cargo.toml --workspace` right
after the bump: it updates only the workspace member's version in the lock
and leaves every dependency pin untouched, so --locked still guarantees
reproducible deps. Verified locally — reproduced the exact failure, then
confirmed the sync makes `cargo build --locked` succeed with 6 dependencies
unchanged.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0114TpmrNW4wNXsHq5CR72jQ
The job-level `if:` expression contains a colon (`chore(release):`), which
an unquoted YAML scalar misreads as a mapping value — Gitea rejected the
workflow with "yaml: line 59: mapping values are not allowed in this
context". Double-quote the whole `${{ }}` expression so it is treated as a
string. Verified the file parses end-to-end after the change.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0114TpmrNW4wNXsHq5CR72jQ
Auto-build and release the Rust sidecar on every push to main.
A language-agnostic "release engine" computes the next version from
conventional-commit subjects since the last v* tag (feat!/BREAKING ->
major, feat -> minor, fix|perf -> patch; first run ships the current
Cargo.toml version). An isolated "Rust adapter" runs cargo fmt --check /
test, builds x86_64-unknown-linux-gnu, and cross-builds
x86_64-pc-windows-gnu via MinGW (libsqlite3-sys is the only native dep).
It then commits the version bump ([skip ci]), tags vX.Y.Z, pushes, and
creates the Gitea release with the linux binary, windows .exe, and
SHA256SUMS.
Reuses the REGISTRY_USER / REGISTRY_TOKEN secrets; the token additionally
needs write:repository scope and main must accept a direct push.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0114TpmrNW4wNXsHq5CR72jQ
