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>
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
