Farid Zakaria's trynix-preview action puts a link on every pull request that boots the 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 flagged 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 shipped 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 shipped 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 hooks into 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 while to boot 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 collapses a class of preview infrastructure into 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.