Farid Zakaria's trynix-preview boots each pull request's build in a browser tab

Farid Zakaria published trynix on 4 September, then followed on 9 September with a companion GitHub action called trynix-preview. The action leaves a comment on every pull request with a link that, when clicked, boots that pull request's build inside the reviewer's browser tab. Simon Willison highlighted the pair on 10 September, calling trynix Zakaria's "magnum opus of Nix work". The trynix GitHub repository has 117 stars in the seven days since it was created, under an MIT licence.

What trynix does

trynix.dev runs a qemu-wasm x86_64 Linux kernel inside a browser tab through WebAssembly, and lets that virtual machine boot with any Nix package that nixpkgs has released over the past thirteen years. The packages are URL-addressable: opening https://trynix.dev/?pkg=python3@3.6.2 boots a shell with Python 3.6.2 from 2017 on the PATH, with no server on the other end. Two versions of the same package can be booted side by side without conflict, because every binary in the Nix store names its own dependencies by absolute path down to the loader and libc.

Zakaria describes the pieces this sits on: nixpkgs-multiverse, which indexes every version of every package nixpkgs has ever released and maps an attribute-and-version pair to a store path; omniflake, which lets a single input pull in over sixteen thousand flakes; and qemu-wasm, an outside project by ktock that runs a Linux kernel in WebAssembly. The browser fetches the store paths from cache.nixos.org and mounts them into the VM's filesystem over 9p.

The GitHub action

trynix-preview is a marketplace GitHub action that connects to a project's existing Nix build. Once a pull request's code has been built and pushed to a Nix cache, the action does one job: it reads the resulting store paths with nix eval, hands the cache URL and public key to trynix, and leaves a comment on the pull request with a link that boots the built binary in the reviewer's browser. Nothing gets built or cached by the action itself. Zakaria demonstrates it on a real pull request against his own sqlelf project, from a fork, where clicking the comment link boots a Linux machine with that PR's sqlelf on the PATH.

For a fork's pull request the workflow runs on the default branch and checks out the PR's code, so a fork cannot edit the workflow that builds it. A second variant lets a maintainer trigger the build by typing /trynix in a comment. Zakaria recommends Cachix as the cache because it is free for open source up to 5 GiB, but the action is not tied to any one Nix cache provider. The caveat the tutorial states plainly: the build must already exist in a cache the browser can reach, and qemu-wasm is best suited to small and medium-sized binaries today, because large ones take a long time to start in a tab.

The change to a review workflow is concrete: instead of "check out the branch, run the build, run the thing" or a full CI-hosted preview environment, a reviewer opens a comment and gets a running shell with the PR's binary on the PATH. That reduces a whole category of preview infrastructure to a link and a browser tab, at least for projects that already build with Nix.

Source

Farid Zakaria's post Review a pull request by booting it, his earlier Any Nix package, live in your browser, and Simon Willison's link, Any Nix package, live in your browser. The action is at marketplace/actions/trynix-preview and the platform is at trynix.dev.