The three artifacts that make this module installable and checkable, closing
phase 3's extraction. Nothing about what the module serves changes: the same 72
URLs, the same behaviour.
**The OpenAPI fragment (MODULE_API.md §2.8, §6.1a) was never built, on either
side.** The 417 `#swagger` annotations came across in slice 1 and went nowhere,
and core's /api/docs.json merged nothing — so every route this module serves was
in no spec at all, which is core's standing rule ("never ship a route that isn't
in the spec") being broken by the extraction rather than by a route.
`server/scripts/swaggerFragment.js` generates it. The prefixes are DERIVED: the
script runs the module's own `register()` against a recording api and asks
`require.cache` which file each router came from, so a mount prefix exists in one
place — `server/index.js` — and not in a table beside it. The 31 schemas moved
here from core's swagger.js, namespaced `Uo…` because core wins every key
collision in the merge; `Error` and `ValidationError` stay referenced by core's
names, since they resolve in the merged document.
**The frozen route manifest (§5.3)** is derived too, and by subtraction: CI
clones core at the ref pinned in ci/core-ref.json, generates its manifest without
this module and then with it, and the difference is what this module serves. That
buys the half of §5.3 that matters most for free — a module that shadowed or
displaced one of core's routes shows up as a REMOVAL, not merely as an addition
elsewhere. The same job checks the fragment against ground truth: every route
must have an operation and every operation must be a route.
**The release workflow** publishes `module-uo-<version>.tar.gz` plus a manifest
carrying its sha256. The version is declared in module.json rather than computed
from commit subjects, and the workflow never writes to a branch — it tags and
publishes — so `main` needs no push exception. The bundle is assembled from an
include list, because an exclude list ships whatever it forgot.
Four annotation defects, inherited from core and never visible until something
generated a spec from these files: two `requestBody` literals a brace short (the
route documented with an empty body), and two descriptions whose inner quoting
swagger-autogen cannot survive — it re-quotes `"` and a backtick to `'` before
evaluating, so either inside a single-quoted description ends the string early
and the annotation is dropped. It reports each one and then prints Success in
green, so the generator now captures its diagnostics and makes them fatal.
Also fixed while writing it: passing one shared `doc` to swagger-autogen six
times. It renders components.schemas from an EXAMPLE object and writes the result
back into what it was handed, so each pass re-wrapped the last and the fragment
came out at 484 MB.
- 409 server tests (+21), 40 client tests unchanged
- swagger-fragment.json: 69 paths covering all 72 routes
- routes.manifest.json: 72 routes; core's own surface unchanged, 0 removals
- verified end to end by assembling the bundle exactly as CI will, unpacking it
into a real core and regenerating the manifest
Refs: docs/website/MODULE_SYSTEM.md §2.7.1, MODULE_API.md §2.8, §5.3, §6.1a
Co-Authored-By: Claude <noreply@anthropic.com>
198 lines
8.6 KiB
YAML
198 lines
8.6 KiB
YAML
# Gate every pull request into `main` on a fast, DB-free check suite, so a broken
|
|
# build or a failing test can't reach the branch that gets released.
|
|
#
|
|
# Mirrors RunicGateway/website's pr-checks.yml — this module is two npm packages
|
|
# shaped like that repo's `server/` and `client/`, and it is loaded into that
|
|
# repo's process, so it is checked the same way with the same Node version.
|
|
#
|
|
# ── What each job is really asking ───────────────────────────────────────────
|
|
#
|
|
# The tests are the ordinary half. The two `check:*` scripts are the interesting
|
|
# one, because they are the acceptance criteria of the module contract itself
|
|
# (docs/website/MODULE_API.md Part 5) rather than of this module's behaviour:
|
|
#
|
|
# • `server: check:imports` — no relative path escapes the module root, and no
|
|
# shipped file resolves a bare specifier. A module that reaches into core's
|
|
# tree works right up until core moves a file, and the whole boundary is
|
|
# worth exactly as much as this check is (§5.1).
|
|
#
|
|
# • `client: check:externals` — the BUILT chunk has no bare imports left. That
|
|
# failure is invisible in source: `import { useState } from 'react'` is
|
|
# correct in every file, and whether it becomes core's React or a bare
|
|
# specifier no browser can resolve is decided by vite.config.js. It has to
|
|
# be asked of the artifact, so it runs after the build. (The other half —
|
|
# a shared dependency being BUNDLED — fails the build itself, from a
|
|
# resolution-time guard inside vite.config.js.)
|
|
#
|
|
# Building the chunk in CI is not only a check: it is how the chunk that ships is
|
|
# produced, since an operator never builds (MODULE_SYSTEM.md §1.14).
|
|
#
|
|
# • `server: check:swagger` — `swagger-fragment.json` describes the routes this
|
|
# module registers, today. Core has no way to generate it: core is a prebuilt
|
|
# image, this module arrived on a volume afterwards, and it mounts through a
|
|
# call no static parser can follow. So the fragment core merges into
|
|
# `/api/docs.json` is whatever this repo committed, and a stale one documents
|
|
# a URL surface that does not exist (§2.8).
|
|
#
|
|
# • `frozen-manifest` — the job with the interesting shape. It clones CORE at
|
|
# the ref pinned in `ci/core-ref.json`, generates its route manifest twice
|
|
# (without this module, then with) and takes the difference. That difference
|
|
# is what this module serves, and it is checked three ways: it must match the
|
|
# committed `routes.manifest.json`, it must not have REMOVED or changed one of
|
|
# core's own routes, and every route in it must have an operation in
|
|
# `swagger-fragment.json` — the per-module form of core's rule that a route
|
|
# which isn't in the spec doesn't ship (§5.3, §2.8).
|
|
#
|
|
# Nothing else can ask those questions. Every other check here runs against
|
|
# this repo alone, where a mount prefix is a string in `server/index.js` and a
|
|
# documented path is a string in a JSON file; whether they name the same URL
|
|
# is a fact about a running core, and this is the only job that has one.
|
|
#
|
|
# Still not here, deliberately: nothing. The release workflow is
|
|
# `.gitea/workflows/release.yml` and runs on a tag rather than on a PR.
|
|
#
|
|
# Enforcement (one-time, in the Gitea UI):
|
|
# Repository Settings → Branches → Branch Protection (rule for `main`)
|
|
# • Enable Status Check
|
|
# • Status check patterns: PR Checks / *
|
|
# Note: Gitea only lists a context in its dropdown after it has reported once,
|
|
# so let this workflow run on one PR first. The `PR Checks / *` glob matches
|
|
# without needing the dropdown, and keeps matching as jobs are added.
|
|
#
|
|
# Runner: the shared self-hosted `ubuntu-latest` runner. These jobs need only
|
|
# Node — no Docker socket, no database.
|
|
|
|
name: PR Checks
|
|
|
|
on:
|
|
pull_request:
|
|
branches: [main]
|
|
|
|
# A newer push to the same PR cancels the in-flight run.
|
|
concurrency:
|
|
group: pr-checks-${{ github.ref }}
|
|
cancel-in-progress: true
|
|
|
|
jobs:
|
|
server-tests:
|
|
runs-on: ubuntu-latest
|
|
timeout-minutes: 20
|
|
steps:
|
|
- uses: actions/checkout@v4
|
|
|
|
- uses: actions/setup-node@v4
|
|
with:
|
|
node-version: 20
|
|
cache: npm
|
|
cache-dependency-path: server/package-lock.json
|
|
|
|
# `npm ci` rather than `npm install`: it also proves the lockfile is in
|
|
# sync with package.json instead of silently updating it.
|
|
- name: Install server deps
|
|
run: npm ci --prefix server
|
|
|
|
- name: Run server tests
|
|
run: npm test --prefix server
|
|
|
|
- name: Check the module boundary (MODULE_API.md §5.1)
|
|
run: npm run check:imports --prefix server
|
|
|
|
- name: Check the OpenAPI fragment is current (MODULE_API.md §2.8)
|
|
run: npm run check:swagger --prefix server
|
|
|
|
client-build:
|
|
runs-on: ubuntu-latest
|
|
timeout-minutes: 20
|
|
steps:
|
|
- uses: actions/checkout@v4
|
|
|
|
- uses: actions/setup-node@v4
|
|
with:
|
|
node-version: 20
|
|
cache: npm
|
|
cache-dependency-path: client/package-lock.json
|
|
|
|
- name: Install client deps
|
|
run: npm ci --prefix client
|
|
|
|
# The build comes FIRST, and that ordering is load-bearing as of slice 3.
|
|
# Two of the client tests read `dist/entry.js` — the chunk's externals, and
|
|
# what it registers when imported against a fake `window.__rg` — and both
|
|
# skip when there is no build. Run the other way round they skip silently
|
|
# in CI, which is the worst of both: green, and not asking the question.
|
|
- name: Build the client chunk
|
|
run: npm run build --prefix client
|
|
|
|
- name: Run client tests
|
|
run: npm test --prefix client
|
|
|
|
- name: Check the built chunk's externals (MODULE_API.md §3.6)
|
|
run: npm run check:externals --prefix client
|
|
|
|
# ── The URLs this module actually serves ──────────────────────────────────
|
|
#
|
|
# Everything above proves the module against itself. This proves it against a
|
|
# real core: the one place where "the prefix I register" and "the path I
|
|
# document" are the same fact rather than two strings that ought to agree.
|
|
#
|
|
# The module is COPIED into the core checkout, never symlinked — core's loader
|
|
# filters its scan with `entry.isDirectory()`, which reports a link as a link
|
|
# and skips it silently, so a symlinked module produces a manifest with no
|
|
# module routes in it and a diff that looks like the module registering
|
|
# nothing.
|
|
frozen-manifest:
|
|
runs-on: ubuntu-latest
|
|
timeout-minutes: 20
|
|
steps:
|
|
- uses: actions/checkout@v4
|
|
with:
|
|
path: module
|
|
|
|
- uses: actions/setup-node@v4
|
|
with:
|
|
node-version: 20
|
|
|
|
# Anonymous HTTPS, and a full clone rather than a shallow one: the pin is a
|
|
# commit sha, and `--depth 1` can only fetch a branch tip.
|
|
- name: Clone core at the pinned ref (MODULE_API.md §5.3)
|
|
run: |
|
|
REPO=$(node -p "require('./module/ci/core-ref.json').repo")
|
|
REF=$(node -p "require('./module/ci/core-ref.json').ref")
|
|
echo "core: $REPO @ $REF"
|
|
git clone --quiet "$REPO" core
|
|
git -C core checkout --quiet "$REF"
|
|
|
|
- name: Install core's server deps
|
|
run: npm ci --prefix core/server
|
|
|
|
# Core alone. `--check` first, so a pin that no longer regenerates its own
|
|
# committed manifest fails HERE, naming the pin, instead of showing up below
|
|
# as this module having removed a route it never touched.
|
|
- name: Generate core's manifest without this module
|
|
run: |
|
|
npm run routes:manifest --prefix core/server -- --check
|
|
cp core/server/routes.manifest.json before.json
|
|
|
|
# The chunk has to exist before the loader will accept the module at all —
|
|
# `client.entry` is validated during the manifest step of the scan, and a
|
|
# missing one is a load failure, not a warning.
|
|
- name: Build the client chunk
|
|
run: |
|
|
npm ci --prefix module/client
|
|
npm run build --prefix module/client
|
|
|
|
- name: Install the module into core
|
|
run: |
|
|
mkdir -p core/modules/uo
|
|
tar -C module --exclude=.git --exclude=node_modules -cf - . | tar -C core/modules/uo -xf -
|
|
npm ci --omit=dev --prefix core/modules/uo/server
|
|
|
|
- name: Generate core's manifest with this module
|
|
run: |
|
|
npm run routes:manifest --prefix core/server
|
|
cp core/server/routes.manifest.json after.json
|
|
|
|
- name: Check the frozen manifest and the fragment's coverage
|
|
working-directory: module
|
|
run: node server/scripts/frozenManifest.js --before ../before.json --after ../after.json --check
|