mr.zeroandClaude Opus 5
526c67b069
ci/woodpecker/manual/woodpecker Pipeline was successful
A store no longer needs a repository of its own. The engine's built-in defaults already cover the host-to-asset mapping, the install modes, the platforms and the behaviour; what they cannot know is identity — a slug, a name and a catalog URL — and that is exactly what a registry record carries. So `storeRepositoryUrl` is optional: a record with a name and a catalog is a complete store, the id falls back from the repository name to the catalog host (`teletypegames.org` becomes `teletypegames`) to the display name, and the client writes a three-section config. Given a repository it still reads it, and that file stays the authority on how the store behaves; a repository without a config.json is treated as no repository at all. Measured end to end against a local registry serving one record with a null repository: the engine and the core downloaded, engine 1.1.0 accepted the written config, it listed the same ten titles the configured store does, and a hosted title synced into a sandbox with its menu entry written. The "Install all" button is gone, and with it the string it used. Titles are installed one at a time from their own cards. No footer. The window carried a bar at the bottom at all times — a toggle and a line of absolute paths — for something most sessions never need. The log is still there, folder buttons included, behind a quiet switch at the bottom of the side menu; it takes no room until it is opened, and an arriving line does not open it, because the store logs on every refresh and a window that unfolds panels by itself is worse than one that keeps quiet. Three faults that every automated count had passed, found by photographing the setup screen: the store badge rendered as an empty pill with no store open; the gate's picker showed as an empty dropdown stub, because an explicit `display` beats the browser's own `[hidden]` rule; and the gate went up while the empty-catalog line stayed on screen underneath it. The last was a design fault — whether the gate is up was a call on a view rather than state, so the two could disagree. The setup screen is now a field in the state store, and that one field decides which of the gate and the grid is drawn. The window test's gate assertion was wrong too: it demanded a store picker, which only appears when the registry offers more than one store, so one store — the ordinary case — failed it. CI builds the packages this machine cannot. `.woodpecker.yaml` runs the checks on every push and, on a tag or by hand, builds the Linux packages in `electronuserland/builder:22` and the Windows ones in `:22-wine`, then attaches them to the release with scripts/ci-upload.sh. The pipeline lives here rather than in the update server's `/build/config` extension, which serves game-platform pipelines publishing into the site's catalog — a different product with a different target. macOS stays a local build: Apple's toolchain and its signing exist only on a Mac. Both build steps verify what they produced, because a half-finished Wine build leaves a 162 KB stub named like the real installer and `ls` is happy with it. The Linux step was rehearsed locally in the same image (AppImage 128 MB, deb 100 MB); the Wine step cannot be rehearsed on Apple Silicon, where 16 KB host pages break Wine's 4 KB assumption, so the runner is where it is proven. The size check was tested against both outcomes. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
70 lines
2.4 KiB
YAML
70 lines
2.4 KiB
YAML
# The pipeline lives in the repository rather than in the update server's
|
|
# `/build/config` extension. That extension serves game-platform pipelines, which
|
|
# build a cartridge and publish it into the site's catalog; this one builds a desktop
|
|
# application and publishes it to a Gitea release. Different product, different target.
|
|
#
|
|
# What CI can and cannot do here: Linux and Windows packages are built in containers —
|
|
# Windows through Wine — while the **macOS package stays a local build**, because
|
|
# Apple's toolchain and its signing exist only on a Mac. A release therefore gets its
|
|
# Linux and Windows assets from this pipeline and its macOS assets from `make release`.
|
|
when:
|
|
- event: [push, manual]
|
|
branch: master
|
|
- event: tag
|
|
|
|
variables:
|
|
# The official electron-builder images: Node with the packaging tools, and the same
|
|
# image plus Wine, which is what lets a Windows installer be built on Linux.
|
|
- &node_image 'electronuserland/builder:22'
|
|
- &wine_image 'electronuserland/builder:22-wine'
|
|
|
|
steps:
|
|
- name: check
|
|
image: *node_image
|
|
commands:
|
|
- node --version
|
|
- npm ci
|
|
- npm run typecheck
|
|
- npm run lint
|
|
# The window test wants a display and a store on the machine; that check belongs
|
|
# where there is one. The bridge check is worth running here: it exercises the
|
|
# registry and the message bundles.
|
|
- |
|
|
if command -v python3 >/dev/null 2>&1; then
|
|
npm run smoke
|
|
else
|
|
echo "no python3 in the image — the smoke test needs it, skipping"
|
|
fi
|
|
|
|
# A quarter of a gigabyte of packages is not worth building on every push, so the
|
|
# two builds run when a release is being cut — or when asked for by hand.
|
|
- name: linux
|
|
image: *node_image
|
|
commands:
|
|
- npm run dist:linux
|
|
- scripts/ci-verify-packages.sh '*.AppImage' '*.deb'
|
|
when:
|
|
- event: [tag, manual]
|
|
|
|
- name: windows
|
|
image: *wine_image
|
|
commands:
|
|
- npm run dist:win
|
|
- scripts/ci-verify-packages.sh '*.exe'
|
|
when:
|
|
- event: [tag, manual]
|
|
|
|
# Only on a tag, and only what this pipeline built: the macOS assets are uploaded
|
|
# from the Mac that can sign them.
|
|
- name: release
|
|
image: alpine
|
|
environment:
|
|
GITEA_TOKEN:
|
|
from_secret: gitea_token
|
|
commands:
|
|
- apk add --no-cache curl jq
|
|
# No globs on the command line: the package names have spaces in them.
|
|
- scripts/ci-upload.sh
|
|
when:
|
|
- event: tag
|