mr.zeroandClaude Opus 5
06f3f2a3b1
Reading the catalog, choosing the release that fits this machine, unpacking it,
writing the menu entry and remembering what went where all happen in process now.
There is no interpreter to find, no child process, and no JSON-lines protocol
between the two halves — `PythonEngineProcessRunner`, the runtime locator, the two
engine mappers and the version negotiation are all gone, and with them the one
unchecked cast this codebase had (engine stdout to a typed event).
What that buys a person: on Windows and on a fresh Mac the app simply works. It
used to look for `python3`, `python` and `py -3` and draw a link to python.org
where none answered.
What lands on disk is unchanged, deliberately. `config.json` and `state.json` keep
the shell engine's snake_case shape, its `<scope>:<name>` keys and its file modes,
so a machine whose library was installed by the CLI keeps it — verified against the
Python engine on the same catalog: the same 13-title listing with zero field
differences, byte-identical payloads, identical modes and an identical Info.plist,
and a re-sync over a Python-installed home that writes nothing. Remove, prune,
prune-suppression on a named sync and the v1 state migration were each exercised.
Three things worth knowing about the new code:
- the zip reader is ~150 lines over `node:zlib`, because Node has none and this
application has no runtime dependencies. It restores the executable bit from
each entry's external attributes, without which nothing installed can start,
and it refuses zip64, unknown compression and paths that escape the
destination rather than guessing;
- `SUPPORTED_WARP_ENGINE_VERSIONS` names the engine versions this client is
written against, checked against the `WarpEngine-Version` header every
response carries. `selectCatalogDialect` switches over that list exhaustively,
so adding a version fails the build — type checker and linter both — until
somebody says what its catalog reads like. An absent header is read as the
oldest version, which is what an engine before 0.4.0 is;
- refresh and the language picker are icons at the foot of the side menu now,
both named for a tooltip and a screen reader, the picker still a real
`<select>` under its glyph.
The repository is free of Python as well: the Makefile, the CI check and the
release script read package.json and the forge's JSON with Node.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
69 lines
2.6 KiB
YAML
69 lines
2.6 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 runs here unconditionally — it needs nothing
|
|
# but Node, now that the store engine is part of the application.
|
|
- npm run smoke
|
|
|
|
# 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:
|
|
# Needed. Woodpecker does hand steps a forge credential — a manual build printed
|
|
# one — but a build started by the tag webhook does not get it: the first tag build
|
|
# died here with no credential at all. So the token is a repository secret, and the
|
|
# script still falls back to the forge credential when it is there.
|
|
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
|