wtclaude
ebbfab51fc
Phase 0 item 1 of the installer plan (docs/installer/PLAN.md §5). The
installer deploys the plugin from a release tarball rather than from git,
because the shard host gets neither git nor Gitea credentials — but this
repo published no releases at all, so there was nothing for it to fetch.
`link` was the only repo with a release workflow.
Reuses link/.gitea/workflows/release.yml's conventional-commit engine, as
that file's own header anticipated: the plan and release steps consume only
{version, changelog, artifacts}. Three things had to change, each forced by
this repo rather than chosen:
No build. The plugin ships as C# source and ServUO compiles it at boot;
it needs ServUO reference assemblies, so nothing here can be compiled in
CI. The build gates are replaced by structural ones that assert what can
honestly be asserted without a ServUO tree: Bridge.cfg and the Bridge
scripts are present, Scripts.csproj (the silent-build-bug fix) is present,
every .patch parses as a unified diff via `git apply --stat`, and each
patch's companion .cs exists. Each of those has a way of shipping broken
and only failing on an operator's live shard.
No bump commit, so no push to main. link writes the version into
Cargo.toml because the binary embeds it; a tarball embeds nothing but the
manifest CI generates, so the git tag is the version. This workflow
therefore never needs main to accept a direct push — no branch-protection
exception for it.
A manifest. The tarball carries manifest.json: version, commit, declared
protocol version, ServUO compatibility, and a SHA256 per shipped file.
The manifest matters more than it looks. The plugin announces no version on
the wire and none is queryable before ServUO boots (PLAN.md §2.6), so its
declared protocol version is the ONLY thing that lets the installer's bundle
CI verify sidecar/overlay agreement before an operator installs the pair
(PLAN.md §7.1 gate 1). That declaration lives in the new overlay.toml
alongside the ServUO compatibility values, so it is one commented line to
maintain rather than a literal buried in a workflow — currently protocol 3,
per docs/link/v3.md.
Tarball layout uses a FIXED top-level directory (runicgateway-overlay/)
rather than a versioned one, so the installer can find overlay/, patches/
and manifest.json at known paths instead of parsing the version it is trying
to read. tar's member order, mtime and ownership are pinned, so a given tree
produces a byte-identical tarball and its checksum changes only when the
contents do.
Verified locally against the real tree before pushing: YAML parses, all six
run blocks pass bash -n, the plan step produces v0.1.0 from actual history,
the gates pass (22 bridge scripts, all three patches parse), the manifest
renders with protocol=3 and 30 file hashes, and two consecutive builds of
the tarball produce the same SHA256.
One real bug caught by running it rather than reading it: sha256sum marks
binary mode by prefixing the path with `*` instead of the two-space
text-mode separator, which would have put a leading `*` on every key in the
manifest. The capture now tolerates both.
Not included: the workflow-dispatch call into the installer's bundle CI
(PLAN.md §7.2). That is Phase 0 item 3 and there is nothing to dispatch yet;
the insertion point is marked in the header. A step that 404s on every
release is worse than no step.
Co-Authored-By: Claude <noreply@anthropic.com>
43 lines
2.3 KiB
TOML
43 lines
2.3 KiB
TOML
# Release metadata for the deployable overlay.
|
|
#
|
|
# Consumed by .gitea/workflows/release.yml, which folds these values into the
|
|
# manifest.json shipped inside runicgateway-overlay-<ver>.tar.gz. The Runic
|
|
# Gateway installer reads that manifest to decide what it is deploying and
|
|
# whether it is compatible with the sidecar it is about to install
|
|
# (docs/installer/PLAN.md §5 Phase 0, §7.1).
|
|
#
|
|
# There is deliberately NO version key here. The release version is derived from
|
|
# git tags and conventional commits by the release workflow, so there is no bump
|
|
# commit to keep in sync and no way for this file to disagree with the tag.
|
|
|
|
# ── The loopback wire-protocol version this overlay speaks ───────────────────
|
|
#
|
|
# This is the plugin half of the compatibility contract. It MUST equal the
|
|
# sidecar's PROTOCOL_VERSION (link/sidecar/src/main.rs) for a deployment to
|
|
# work: the sidecar rejects a mismatch with 409 rather than mis-parsing.
|
|
#
|
|
# The C# plugin has no queryable version before ServUO boots — it does not
|
|
# announce one on the wire — so this declaration is the only thing that lets the
|
|
# installer's bundle CI check the pair BEFORE an operator installs them
|
|
# (docs/installer/PLAN.md §2.6, §7.1 gate 1). Keeping it honest is therefore a
|
|
# manual duty: when the protocol changes, bump it here in the same PR that
|
|
# changes the emitters, exactly as link bumps PROTOCOL_VERSION.
|
|
#
|
|
# Current: 3 — see docs/link/v3.md (world.ruleset, points.board, vendor.listing).
|
|
protocol = 3
|
|
|
|
# ── ServUO compatibility ─────────────────────────────────────────────────────
|
|
#
|
|
# The base overlay (Config/Bridge.cfg + Scripts/Custom/Bridge/*.cs) only ADDS
|
|
# files and is expected to work on any reasonably current ServUO. This is the
|
|
# oldest version it is known good on.
|
|
min_servuo_version = "57.4"
|
|
|
|
# The patches/ tier is a different matter: those are unified diffs against STOCK
|
|
# ServUO files, so they are verified against exactly one version and nothing
|
|
# else. On any other version the installer skips the whole tier with a warning
|
|
# and completes the base install (docs/installer/PLAN.md §1, §2.2) — losing
|
|
# vendor.sale events and in-game moderation-audit forwarding, but never
|
|
# half-patching an unknown tree.
|
|
patches_verified_against = "57.4"
|