ci(installer): add pr-checks, release, and project-tree sync workflows #1

wtclaude · 2026-08-04T14:15:31Z

wtclaude commented

2026-08-04 14:15:31 +00:00

What & why

Brings this repo's CI to parity with the other Runic Gateway repos. All three workflows are retargeted from RunicGateway/link, the closest analog — same Rust toolchain, same release engine, same runner.

File	What it does
`.gitea/workflows/pr-checks.yml`	Gates PRs into `main` on `cargo fmt --check`, `clippy -D warnings`, `cargo test --locked` — one job, same order as the release's own gates, so a green PR implies a green release.
`.gitea/workflows/release.yml`	The conventional-commit release engine from `link/`, Rust adapter retargeted: crate at the repo root, binary `runicgateway-installer`, cross-compiled for x86_64 Linux + Windows. Artifact names follow PLAN.md §3.
`.gitea/workflows/sync-project-tree.yml` + `.gitea/scripts/gen_tree.py`	Regenerates `docs/installer/PROJECT_TREE.md` on push to `main` and opens/force-updates a PR against the docs repo. Verbatim from `link/` apart from the repo/path/label env block.

Two deliberate changes from the link originals:

1. The crate guard. This repo has no Cargo project yet — Phase 1 creates it. Landing the Rust workflows unguarded would red-X every governance and docs PR until then; holding them back leaves the repo ungated exactly while its conventions are being set. So both check for a root Cargo.toml first: pr-checks skips its gates with a notice, and release.yml's plan step sets RELEASE=false and exits 0. Both arm themselves the moment Cargo.toml lands, with no edit here.

2. Checksum instructions in the generated changelog. Installer releases are deliberately unsigned and SHA256SUMS is the trust anchor (PLAN.md §3), so the verify commands for both OSes are rendered into every release body rather than living in a doc an operator has to go find.

The crate is expected at the repo root, not a subdirectory like link/sidecar — this repo's sole product is the one installer binary, so there's nothing to namespace it against.

How it was tested

Locally, before pushing:

All three files parse as YAML (yaml.safe_load).
Every run: block extracted and passed bash -n (18 blocks).
release.yml's plan step simulated against a throwaway git repo:
- no Cargo.toml → release=false, exit 0, no other step runs;
- with a Cargo.toml + one feat: commit → first-release path, version=0.1.0, tag=v0.1.0, changelog rendered correctly including the verification block.
gen_tree.py run against this repo's tracked files — renders the expected tree.

This PR is also the first exercise of pr-checks.yml itself, which is what the enforcement note in its header needs: Gitea only offers a status-check context in the branch-protection dropdown after it has reported once.

Setup still required

release.yml and sync-project-tree.yml need REGISTRY_USER / REGISTRY_TOKEN configured for this repo (Settings → Actions → Secrets) — write:repository here, plus read/write on RunicGateway/docs for the tree sync. I can't read this repo's secrets with my token, so if they aren't inherited from the org they'll need adding before the first merge to main.

Not included

The bundle-manifest workflow and the release-dispatch hook (PLAN.md §7) — those are Phase 0 item 3 and depend on servuo-plugins gaining a release workflow first.

Checklist

I have read CONTRIBUTING.md.
The change builds and existing tests/checks pass locally.
I have added or updated tests/docs where it makes sense.
My commits are reasonably scoped with clear messages.

AI-assisted contributions (required)

AI tools were used. Tool(s): Claude Code (Claude Opus 5). Every change has been reviewed and is understood. AI-authored commits are marked with a Co-Authored-By trailer.

License

I agree that my contribution is licensed under this project's license (GNU GPL v3.0 or later), and I have the right to contribute it.

## What & why Brings this repo's CI to parity with the other Runic Gateway repos. All three workflows are retargeted from [`RunicGateway/link`](https://gitea.whitlocktech.com/RunicGateway/link), the closest analog — same Rust toolchain, same release engine, same runner. | File | What it does | |---|---| | `.gitea/workflows/pr-checks.yml` | Gates PRs into `main` on `cargo fmt --check`, `clippy -D warnings`, `cargo test --locked` — one job, same order as the release's own gates, so a green PR implies a green release. | | `.gitea/workflows/release.yml` | The conventional-commit release engine from `link/`, Rust adapter retargeted: crate at the repo root, binary `runicgateway-installer`, cross-compiled for x86_64 Linux + Windows. Artifact names follow [PLAN.md §3](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/installer/PLAN.md). | | `.gitea/workflows/sync-project-tree.yml` + `.gitea/scripts/gen_tree.py` | Regenerates `docs/installer/PROJECT_TREE.md` on push to `main` and opens/force-updates a PR against the docs repo. Verbatim from `link/` apart from the repo/path/label env block. | Two deliberate changes from the `link` originals: **1. The crate guard.** This repo has no Cargo project yet — Phase 1 creates it. Landing the Rust workflows unguarded would red-X every governance and docs PR until then; holding them back leaves the repo ungated exactly while its conventions are being set. So both check for a root `Cargo.toml` first: `pr-checks` skips its gates with a notice, and `release.yml`'s plan step sets `RELEASE=false` and exits 0. Both arm themselves the moment `Cargo.toml` lands, with no edit here. **2. Checksum instructions in the generated changelog.** Installer releases are deliberately **unsigned** and `SHA256SUMS` is the trust anchor (PLAN.md §3), so the verify commands for both OSes are rendered into every release body rather than living in a doc an operator has to go find. The crate is expected at the **repo root**, not a subdirectory like `link/sidecar` — this repo's sole product is the one installer binary, so there's nothing to namespace it against. ## How it was tested Locally, before pushing: - All three files parse as YAML (`yaml.safe_load`). - Every `run:` block extracted and passed `bash -n` (18 blocks). - `release.yml`'s plan step simulated against a throwaway git repo: - **no `Cargo.toml`** → `release=false`, exit 0, no other step runs; - **with a `Cargo.toml` + one `feat:` commit** → first-release path, `version=0.1.0`, `tag=v0.1.0`, changelog rendered correctly including the verification block. - `gen_tree.py` run against this repo's tracked files — renders the expected tree. This PR is also the first exercise of `pr-checks.yml` itself, which is what the enforcement note in its header needs: Gitea only offers a status-check context in the branch-protection dropdown after it has reported once. ## Setup still required `release.yml` and `sync-project-tree.yml` need `REGISTRY_USER` / `REGISTRY_TOKEN` configured for this repo (Settings → Actions → Secrets) — `write:repository` here, plus read/write on `RunicGateway/docs` for the tree sync. I can't read this repo's secrets with my token, so if they aren't inherited from the org they'll need adding before the first merge to `main`. ## Not included The bundle-manifest workflow and the release-dispatch hook (PLAN.md §7) — those are Phase 0 item 3 and depend on `servuo-plugins` gaining a release workflow first. ## Checklist - [x] I have read [CONTRIBUTING.md](CONTRIBUTING.md). - [x] The change builds and existing tests/checks pass locally. - [x] I have added or updated tests/docs where it makes sense. - [x] My commits are reasonably scoped with clear messages. ## AI-assisted contributions (required) - [x] AI tools were used. Tool(s): `Claude Code (Claude Opus 5)`. Every change has been reviewed and is understood. AI-authored commits are marked with a `Co-Authored-By` trailer. ## License - [x] I agree that my contribution is licensed under this project's license (**GNU GPL v3.0 or later**), and I have the right to contribute it.

wtclaude added 1 commit 2026-08-04 14:15:32 +00:00

ci(installer): add pr-checks, release, and project-tree sync workflows

PR Checks / rust-gates (pull_request) Successful in 11s

Details

ea9aad6e9b

Bring this repo's CI up to parity with the other Runic Gateway repos. All
three are retargeted from RunicGateway/link, which is the closest analog
(same Rust toolchain, same release engine, same runner).

pr-checks.yml
  Gates PRs into main on cargo fmt --check, clippy -D warnings, and
  cargo test --locked, in that order, one job — mirroring release.yml's
  gates so a green PR implies a green release.

release.yml
  The conventional-commit release engine from link/, with the Rust
  adapter retargeted: crate at the repo root, binary
  runicgateway-installer, cross-compiled for x86_64 Linux and Windows.
  Artifact names follow PLAN.md §3. The generated changelog now carries
  the checksum-verification block, because releases are deliberately
  unsigned and SHA256SUMS is the trust anchor (PLAN.md §3) — that makes
  the verify instructions part of the release, not a doc someone has to
  find.

sync-project-tree.yml (+ .gitea/scripts/gen_tree.py)
  Regenerates docs/installer/PROJECT_TREE.md on every push to main and
  opens or force-updates a PR against the docs repo. Verbatim from link/
  apart from the repo/path/label env block.

Crate guard
  This repo has no Cargo project yet — Phase 1 creates it. Landing the
  workflows unguarded would red-X every governance and docs PR until
  then, and holding them back leaves the repo ungated exactly while its
  conventions are being set. So both Rust workflows check for a root
  Cargo.toml first: pr-checks skips its gates with a notice, and
  release.yml's plan step sets RELEASE=false and exits. Both arm
  themselves the moment Cargo.toml lands, with no edit here.

Verified before pushing: all three files parse as YAML, every run block
passes bash -n, and the release plan step was simulated against a throwaway
git repo both without a crate (release=false, exit 0) and with one
(first-release path -> v0.1.0 with the changelog rendered).

Not included: the bundle-manifest workflow (PLAN.md §7) and the
release-dispatch hook, which are Phase 0 item 3 and depend on
servuo-plugins having a release workflow first.

Note for setup: release.yml and sync-project-tree.yml need REGISTRY_USER
and REGISTRY_TOKEN (write:repository, plus read/write on RunicGateway/docs)
configured for this repo.

Co-Authored-By: Claude <noreply@anthropic.com>

whitlocktech approved these changes 2026-08-04 14:16:23 +00:00

whitlocktech merged commit 71a9210503 into main

2026-08-04 14:16:30 +00:00

whitlocktech deleted branch ci/add-workflows

2026-08-04 14:16:31 +00:00

whitlocktech referenced this issue from a commit

2026-08-04 14:16:32 +00:00

Merge pull request 'ci(installer): add pr-checks, release, and project-tree sync workflows' (#1) from ci/add-workflows into main

wtclaude referenced this pull request from RunicGateway/docs

2026-08-04 14:30:34 +00:00

docs(installer): record Phase 0 progress and the overlay manifest #82

Sign in to join this conversation.