trynix preview action

Comment a link on a pull request that boots what it built, in the
reviewer's browser.

The action names the store paths a flake attribute produces and posts a
trynix.dev link that mounts them in an x86_64 VM
running in the tab. A reviewer clicks it and gets a shell with the
branch's build on PATH. There is no server and nothing to install.

- uses: cachix/cachix-action@v17
  with:
    name: my-cache
    authToken: ${{ secrets.CACHIX_AUTH_TOKEN }}
- run: nix build .#my-package
- uses: fzakaria/trynix@v1
  with:
    cache: https://my-cache.cachix.org
    publicKey: my-cache.cachix.org-1:0Ma9…
    attrs: .#my-package

It publishes nothing of its own. Whatever already fills your cache keeps
doing it, and the action hands that cache's URL and public key to the
browser, so cachix, attic, an S3 bucket and a directory of narinfos on a
static host are all the same thing to it. It holds no token.

Packages and flake apps both work, several boot together in one VM, and
the comment is edited in place rather than repeated on every push. Pull
requests from forks are supported and
documented,
including what giving a fork's build a push token costs.

Options and example workflows.

This release tracks v1: the tag moves as the action changes and these
notes are updated in place, so there is one version to point at.

engine-20260910-0209

qemu-wasm engine and snapshot, taken against guest k8kmic5pxq0436rpi25a0pi3jbifcyp6-trynix-guest

engine-20260909-1943

qemu-wasm engine built with patches 0001-0007 (0007: cached successor index, direct calls inside a batch, entry mode, inline 64-bit multiply); snapshot unchanged from engine-20260909-1605, taken against guest k8kmic5pxq0436rpi25a0pi3jbifcyp6-trynix-guest

engine-20260909-1605

The wasm backend's new execution model (patches/0006-wasm32-batch-chain-locals.patch, docs/engine-execution.md): blocks compile in batches of 64 after a warm-up with per-block import relocation, compiled blocks tail-call their successors (dispatcher fallback on browsers without tail calls), guest registers in wasm locals. opencode --version 2.4-2.9x faster; hello/ripgrep/jujutsu/python 1.0-1.3x; no regressions in the exec-bench suite. Same snapshot and guest image as engine-20260907-0100.

engine-20260907-0100

qemu-wasm engine and snapshot, taken against guest k8kmic5pxq0436rpi25a0pi3jbifcyp6-trynix-guest

engine-20260906-2123

qemu-wasm engine and snapshot, taken against guest k8kmic5pxq0436rpi25a0pi3jbifcyp6-trynix-guest

engine-20260905-2256

The guest now forces a CRNG reseed as soon as the handshake completes, before anything can consume randomness. Every visitor resumes the same frozen pool, and only a reseed pulls fresh bytes from the CPU instruction QEMU answers out of the browser; until now that reseed fired only because the snapshot happened to be taken at 0.93 s of uptime. A snapshot taken 45 s in gave six identical boot ids from six resumes before this change and six distinct ones after. Engine files unchanged.

engine-20260905-2235

Snapshot retaken with a native binary that counts the same monotonic clock the WebAssembly build counts (patches/0003). The guest was calibrating its TSC against a real rdtsc while it booted natively and then running on a nanosecond clock, so every sleep and timeout in the guest ran 3.3x long: 'sleep 10' took 33 s. It now takes 10.1 s, and the guest reports 1000 MHz, which is what it actually gets. Engine files unchanged.

engine-20260905-2136

The guest now has a source of randomness: +rdrand on the CPU model and a virtio-rng-pci device, with CONFIG_HW_RANDOM_VIRTIO enabled in the kernel. Without one the random pool was empty after a resume and the first program to call getrandom() drove the kernel's TSC-jitter loop: a cold 'jj --version' took 15.2 s, of which 14.2 s was six getrandom() calls. It now takes 0.75 s. Engine files unchanged; snapshot retaken for the new machine.

engine-20260905-1950

Guest kernel rebuilt with CONFIG_VM_EVENT_COUNTERS so /proc/vmstat reports pgfault and friends again; engine files unchanged from engine-20260905-1727.