Hi all! I’d like to share Junix, a small tool that converts Nix @nix JSON output into standard JUnit XML so you can integrate Nix builds with any JUnit-compatible CI (GitLab CI, Jenkins, GitHub Actions, etc.).
Try it:
cd your/flake
nix run gitlab:moduon/junix check -o result.xml
This will:
Eval all systems checks in one shot
If any eval fails, repeat that check’s eval to get full traceback
Build local system checks
Write the JUnit XML report in result.xml with check build logs and eval failure logs, if any
Use of automated tools to develop upstream software packaged inside Nixpkgs is not in scope.
This is not packaged inside Nixpkgs, but it is upstream software. Therefore I didn’t feel obligated to add any assisted-by trailer in this forum. Do we have to add the trailer each time we talk about any upstream project that has any kind of automated assistance?
In any case, the project has its own disclosures as you noticed. It’s not like I wanted to keep that secret… This has been an idea I had for a long time (and reported to nom without success FWIW) but didn’t have the time to develop it. Now it exists! I hope it helps you too.
No, it’s just linking to the wrong policy. The Discourse LLM Policy requires (among other things) disclosure when linking to such projects (in the post, not only on the project site).
As the Discourse policy (not the one you were first linked) says, if the project was substantially LLM-generated, then yes. (‘Substantially’ is left up to your judgment. If you used a Copilot autocomplete a few times, I wouldn’t worry about it.)
(This is largely to prevent the first six posts on the topic from being people fighting over it! You and I both want these announcement threads to be primarily productive discussion of the tool — feedback that you will find useful and observations that other community members will want to see. Prompt disclosure lets the anti-LLM people nope out quickly instead of starting (what I’m sure feels like) an inquisition.)
Thanks! I didn’t know about that other LLM policy here in Discourse. Sorry for not following it.
Regarding nix-fast-build, it reinvents the way Nix evaluates and builds things. After lots of experimentation I never managed to get faster builds with that. Actually the only outcome I possibly got was hitting more often Nix’s RAM leaks more often and all my CI workers died after hitting the limit of 40GiB of RAM (!).
I rely on nixbuild.net and its remote store feature to alleviate my CI load, and that only works fine with normal Nix, but not with nix-fast-build.
Therefore, if all you want is nicer summary output and a JUnit report without reinventing Nix, then Junix is for you. If you benefit from the other things of nix-fast-build, then for sure it’s a better option. Also, you can always use any Nix tool and pipe its logs to Junix, like with nom.
It is not a nixbuild.net feature, it is a nix feature. nixbuild.net provides the infrastructure to use --eval-store auto and friends to let the output closure of your drv be built entirely on their machines. In some cases, i.e. on my nix-on-droid, it might be needed to utilize --print-out-paths on your nix build invocation as well as using that certain path then to nix copy --from ssh-ng://root@nixbuild <store-path> (I also had to use --no-check-sigs as long as I did not sign my builds). Basically I just stick with <store-path>/activate in case I built my system closure that way.
