Files
keluna/docs/samples-linux-amd64.md
mhoennig f7ca150e1f
werkator build succeeded after 01:50
werkator/samples-linux-amd64 build succeeded after 02:49
Build downloadable AMD64 desktop samples after successful tests
2026-09-16 13:15:34 +02:00

2.3 KiB

Keluna desktop samples for Linux AMD64

This archive contains three native desktop applications: counter, snake, and workshop. They use the system WebView and do not require Java or Node.js at runtime. COMMIT records the source revision.

Run

The CI binaries are built on Ubuntu 24.04 for x86-64 (AMD64). They require compatible glibc, GTK 3, and WebKitGTK 4.1 runtime libraries and a graphical desktop session. On Ubuntu 24.04, install the runtime libraries with:

sudo apt install libgtk-3-0t64 libwebkit2gtk-4.1-0

Extract the archive and launch an example from your desktop terminal:

tar -xzf keluna-samples-linux-amd64.tar.gz
cd keluna-samples-linux-amd64
./counter
./snake
./workshop

These are dynamically linked applications, not universal binaries for every Linux distribution. ARM64 and older glibc systems are not supported by this archive. Keep LICENSE, NOTICE, and licenses/ with the executables when redistributing them.

Build pipeline

The default build runs the native and JavaScript tests. After it succeeds, samples-linux-amd64 builds all three desktop applications at the same commit and publishes the archive and its SHA-256 checksum. Both builds are described by the branch's .werkator.yml. A future architecture can have its own follow-up definition, toolchain, and archive.

The host selects the sandbox through Keluna's .git/werkator/.werkator.applied.yml. The shared instance configuration only registers the repository. The sandbox recipe is ci/Dockerfile.samples-linux-amd64. Prepare it on a machine with Docker and zstd:

tools/build-samples-rootfs

The script exports an AMD64 rootfs under build/ with the Docker image ID in its filename. Upload that archive to the build host and configure its absolute path as builds.samples-linux-amd64.werkdock.rootfs in Keluna's applied fragment. Keep builds.default.werkdock.enabled: true and the existing default rootfs for the tests. Give the sample build a separate statusContext, such as werkator/samples-linux-amd64, in the host configuration so its Gitea status does not replace the test status. Do not place the follow-up trigger in the host fragment; it belongs to the branch's .werkator.yml. The image-specific filename ensures Werkdock imports changed contents instead of reusing an old cached rootfs.