# 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:

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

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

```sh
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:

```sh
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.