From 484f00ddee8fb661ff53227822959b6c7b5217f8 Mon Sep 17 00:00:00 2001 From: wtclaude Date: Fri, 7 Aug 2026 16:05:56 -0500 Subject: [PATCH] docs(readme): describe a released installer, not an unreleased one MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The status section still said "Phases 1 to 4 are built, on edge. Nothing is released yet" and told visitors the way to install was by hand — both untrue as of v0.1.0. - Add an "Install a shard with it" section up top: verify, run, paste the four values. That is what a visitor to this repo is here for. - Status: released, all five phases, both cutover gates recorded. - Fix a broken link: bundles/current.json is no longer on main, it lives on the bundles branch. Co-Authored-By: Claude --- README.md | 84 +++++++++++++++++++++++++++++++++---------------------- 1 file changed, 51 insertions(+), 33 deletions(-) diff --git a/README.md b/README.md index 37ea320..3b7d04a 100644 --- a/README.md +++ b/README.md @@ -25,9 +25,48 @@ It also **does not replace ServUO startup behavior.** ServUO keeps running throu its existing release/start scripts; the installer never writes a launcher and never restarts the shard. +## Install a shard with it + +Grab a binary and `SHA256SUMS` from the +[releases page](https://gitea.whitlocktech.com/RunicGateway/installer/releases), +verify the checksum, and run it as Administrator/root against a **stopped** shard: + +```bash +sha256sum -c SHA256SUMS --ignore-missing +chmod +x runicgateway-installer-linux-x86_64 +sudo ./runicgateway-installer-linux-x86_64 install +``` + +```powershell +# Windows, from an elevated PowerShell +.\runicgateway-installer-windows-x86_64.exe install +``` + +It ends by printing the four values to paste into **Admin → Shard** on your site. +The full operator guide — what it asks, where it writes, the patch tier, day-two +commands and troubleshooting — is +[`installer/INSTALL.md`](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/installer/INSTALL.md). + +Prefer to place everything yourself, or on a host that cannot run the binary? +[INSTALL.md Appendix A](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/installer/INSTALL.md#appendix-a--installing-by-hand) +is the same deployment done with `curl`, `tar` and `systemctl`, and stays +supported. + ## Status -**Phases 1 to 4 are built, on the `edge` branch. Nothing is released yet.** +**Released.** All five phases are built and the `edge → main` cutover (#17) cut +the first release, [`v0.1.0`](https://gitea.whitlocktech.com/RunicGateway/installer/releases), +publishing `linux-x86_64`, `linux-aarch64` and `windows-x86_64.exe` with +`SHA256SUMS`. + +| Phase | State | +|---|---| +| 0 — prerequisites in the other repos | ✅ merged | +| 1 — installer core: bundle resolution, ServUO detection, overlay sync, `install.json` | ✅ released | +| 2 — uo-link install + service registration | ✅ released | +| 3 — the opt-in stock-file patch tier | ✅ released | +| 4 — `doctor`, `update`, `uninstall` | ✅ released | +| 5 — packaging polish: Linux `aarch64`, backup before overwrite | ✅ released | The binary does everything [`installer/INSTALL.md`](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/installer/INSTALL.md) @@ -40,39 +79,18 @@ The design of record is in the docs repo: phases, locked decisions, and the Phase 0 prerequisites in other repos (a `servuo-plugins` release workflow, a non-interactive config read-back in `link`, and the bundle-manifest CI here), all of which have landed — -[`bundles/current.json`](bundles/current.json) names the current protocol-checked -sidecar + overlay combination, recomposed on every component release and nightly -(see [`bundles/README.md`](bundles/README.md)). +[`bundles/current.json`](https://gitea.whitlocktech.com/RunicGateway/installer/src/branch/bundles/current.json) +names the current protocol-checked sidecar + overlay combination, recomposed on +every component release and nightly (see [`bundles/README.md`](bundles/README.md)). -| Phase | State | -|---|---| -| 0 — prerequisites in the other repos | ✅ merged | -| 1 — installer core: bundle resolution, ServUO detection, overlay sync, `install.json` | ✅ on `edge` | -| 2 — uo-link install + service registration | ✅ on `edge` | -| 3 — the opt-in stock-file patch tier | ✅ on `edge` | -| 4 — `doctor`, `update`, `uninstall` | ✅ on `edge` | -| 5 — packaging polish: Linux `aarch64`, backup before overwrite | in progress | - -**Why `edge`:** `release.yml` publishes an installer binary on every push to -`main`, so nothing lands there until the whole tool is worth handing to an -operator. The `edge → main` cutover cuts the first release. PRs into `edge` run -the same gates as PRs into `main`. - -**What the cutover is waiting on**, per PLAN.md §5: - -1. **Phase 5**, packaging polish — deliberately *before* the first release rather - than after it, because it changes the release layout, and shipping first would - mean a first release immediately superseded by the next. There is no `.deb` - and no MSI: both would give the sidecar binary, its service unit and its - service account a second owner beside this tool. -2. **The Windows SCM half verified on a real host.** `sc create`, the virtual - service account, the failure actions and the token-file ACL have never been - executed anywhere. Running the *systemd* half for real is what turned up a bug - no unit test had, so this is not a formality. - -Until the cutover, the way to install is by hand — -[INSTALL.md Appendix A](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/installer/INSTALL.md#appendix-a--installing-by-hand) -is the same deployment done with `curl`, `tar` and `systemctl`. +**`main` publishes.** `release.yml` cuts a release from every push to `main`, which +is why the crate was integrated on `edge` until it was worth handing to an +operator. Both cutover gates were met first: Phase 5 (its scope settled as **no +`.deb` and no MSI** — either would give the sidecar binary, its service unit and +its service account a second owner beside this tool), and the **Windows SCM half +verified on a real host**. That second one earned its place: `sc start` failed +with 1053 on its first real run and needed a sidecar fix (link#29) before it +passed 13/13. ## Related repos