nixos-generators
nixos-generators copied to clipboard
GitHub Actions image format builds
Re this comment.
This PR introduces:
- Nix flake check outputs for
x86_64-linux
(almost everything but thesd-aarch64
andsd-aarch64-installer
formats) andaarch64-linux
(only thesd-aarch64
andsd-aarch64-installer
formats), and - A set of GitHub Actions jobs that (a) evaluate the flake checks, (b) attempt to build various formats using
nixos-generate
with appropriate arguments, and (c) attempt to build the Nix flake check outputs.
Submitting as a draft for feedback on scope, design, and plain old fitness for purpose before proceeding further.
Link to a passing GitHub actions run is here (66th time's the charm :smiling_face_with_tear:).
TODO
When to run
Building (almost) all formats is time-consuming, even when running all the builds in parallel. Maybe these jobs should run only upon pull request activity, and not upon every push?
Build artifacts
The GitLab CI setup included exposing the results of the vm
and vm-nogui
builds as artifacts. I've ported this over to the updated GitHub Actions workflow. Not sure what value, if any, this provides.
Caching
Would it be worthwhile to cache build results? With, say, Cachix?
Useless work
Some jobs (e.g., anything involving the cloudstack
format) do a bunch of work -- checking out the repo, installing Nix, etc. -- only to exit without attempting to build anything because the Nix flake doesn't define .#checks.<system>.cloudstack-<nixpkgs>
. This is wasteful.
This useless work could be cut out by duplicating some of the format-exclusion logic from the Nix flake check definitions as exclude
entries in the relevant job matrix.
Complexity
The flake check stuff is pretty hairy. Would welcome feedback on improving the architecture.
Btw. we have also have a self-hosted hercules ci setup in this organisation, which does not need to download all derivations. This might be faster than github actions. There is also an aarch64 builder included for cross-ci builds.
generally this goes in the right direction. I guess we want to build just 3-4 different images on every push (difference between push or PR is not big enough to matter) I guess we should build something like kexec-bundle, container, amazon, iso ? since those are the most commonly used I would guess
Could you maybe move some of your commits not related to CI to a new PR? i.e. https://github.com/nix-community/nixos-generators/pull/155/commits/45504ad7f9aa220fa5dbad661798cead3e2fcd8a looks like no-brainer that we can just merge as is. Than reviewing this will become faster.