trynix-preview: revisar un pull request arrancándolo en el navegador
Una GitHub Action deja un comentario en la PR con un enlace que levanta el build en una Linux dentro de la pestaña. Sin clonar, sin construir y sin servidores.
trynix-preview es una GitHub Action que deja un comentario en el pull request con un enlace. Al abrirlo, el build de esa PR arranca en una máquina Linux dentro de la pestaña del navegador, con el binario del proyecto ya en el PATH. El revisor no clona nada, no compila nada y no toca Docker, máquina virtual, SSH, VPN ni nube. Solo hace clic.
La idea venía de un post anterior sobre trynix, donde el autor listaba lo que se podría hacer si era posible arrancar rutas arbitrarias de /nix/store en el navegador. Lo más obvio era justo esto: que quien revisa una PR pueda probarla antes de aprobarla. Ya funciona, y hay una demo pública: la PR#31 contra el proyecto sqlelf, abierta desde un fork, con el comentario que deja la acción.
Qué necesita para funcionar
El workflow son cuatro líneas. Se configura el caché de Nix (el ejemplo usa Cachix), se compila el código de la PR y se sube al caché, y después entra fzakaria/trynix@v1 con la URL del caché, su clave pública y los atributos que se quieren arrancar. La acción no compila ni cachea nada: su único trabajo es obtener las store paths con nix eval y pasarle al navegador la URL y la clave del caché. No está atada a un proveedor concreto, aunque el autor recomienda Cachix porque su plan gratuito para open source llega hasta 5 GiB.
Hay un detalle de seguridad que conviene no saltarse. Como el workflow se ejecuta sobre el pull request de un fork, hace falta allow-unsafe-pr-checkout: true en el paso de checkout. El autor recomienda además un caché privado y separado para los builds de PR, de forma que un fork no pueda escribir en el caché principal. Si eso no encaja, existe una variante en la que un mantenedor escribe /trynix en la PR y es eso lo que dispara el workflow. En los dos casos el flujo corre sobre la rama por defecto y hace checkout del código de la PR, así que un fork no puede editar el workflow que lo construye.
El techo está en el rendimiento
Esto no jubila a los productos de CI. Con binarios grandes el rendimiento es malo: incluso después de las mejoras que el autor metió en el motor con ayuda de IA, ejecutarlos puede llevar entre uno y dos minutos. Hay una página de benchmarks en trynix.dev con datos de tiempos de arranque y ejecución de varias aplicaciones. Por eso la acción encaja hoy en binarios pequeños y medianos.
Para un revisor, la diferencia es tangible: se pasa de reproducir el entorno a abrir un enlace. El interés ahora está en si el motor aguanta binarios más pesados, porque ahí es donde se decide si esto se queda en una demo vistosa o entra en el flujo de revisión habitual.
