ci: eval for pkgsStatic

[wolfgangwalther]

Now that eval is running nicely in Github Actions, I wonder whether it would be possible to add more systems - just to make sure eval is not easily broken?

Since RFC46 is not really much help to figure out which platforms to do this on, I went grepping:

grep -ohrIE '(Platform|cc|stdenv|bintools)\.(is|use)[^ .]+\b' . | sed -e 's/^.*\.//g' | sort | uniq | xargs -I {} sh -c 'echo -n "{} "; grep -Ir "\b{}\b" . | wc -l'

The idea is: The more conditionals a platform uses in nixpkgs, the more useful an eval CI check is. I ran the numbers and cut off everything below 50 hits.

conditional	n	eval
isDarwin	6366	✔️ ✔️
isLinux	2420	✔️ ✔️
isAarch64	689	✔️ ✔️
isClang	458	✔️ ✔️
isStatic	436
isx86_64	364	✔️ ✔️
isMusl	252
isGNU	186	✔️ ✔️
isWindows	176
isx86	134	✔️ ✔️
isFreeBSD	128
useLLVM	118
is64bit	103	✔️ ✔️ ✔️ ✔️
isAarch32	93
isi686	92
isMinGW	86
isCygwin	71
is32bit	64
isAarch	55	✔️ ✔️
isGhcjs	50

My conclusion: pkgsStatic on x86_64-linux, which covers both isStatic and isMusl is the next logical target. Especially, because eval currently succeeds as well.

I also tried x86_64-freebsd, which would give us isFreeBSD and useLLVM and x86_64-cygwin, which would give us isWindows and isCygwin. Both failed eval right now.

---

Add a 👍 reaction to pull requests you find important.

[wolfgangwalther]

So the x86_64-musl job doesn't return any attr paths, but I think that's expected the way I hacked this up here. Eval took long enough locally, that I assume it did still evaluate something, but I might be wrong. At least freebsd and cygwin failed evaluation locally, so something was surely happening there.

What do we need to do to make this reality (and useful)?

[FliegendeWurst]

I think your change to supportedSystems broke ofborg's eval.

What do we need to do to make this reality (and useful)?

It seems useful in its current form. I don't think we will need to count rebuilds for pkgsStatic, since we usually try to avoid conditional patches.

[wolfgangwalther]

I think your change to supportedSystems broke ofborg's eval.

I'm not sure how to do this correctly - the way I added it to supportedSystems certainly is not.

[infinisil]

The supportedSystems.nix is also tied to what Hydra evals, so I believe this would increase Hydra eval time and job count by 25%. We could decouple GHA from Hydra platforms though, but I think for now we should focus on ensuring a smooth transition to GHA for the existing platform evals and relieving ofborg, before moving on to increase the scope

[wolfgangwalther]

I don't think this actually ever worked as intended; it would need to be done differently anyway.