GitHub Actions image format builds #155
Conversation
TODOWhen to runBuilding (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 artifactsThe GitLab CI setup included exposing the results of the CachingWould it be worthwhile to cache build results? With, say, Cachix? Useless workSome jobs (e.g., anything involving the This useless work could be cut out by duplicating some of the format-exclusion logic from the Nix flake check definitions as ComplexityThe flake check stuff is pretty hairy. Would welcome feedback on improving the architecture. |
tomeon
force-pushed
the
github-actions-image-builds
branch
from
497f5c3 to
1e17cc7
Compare
tomeon
changed the title
|
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. 45504ad looks like no-brainer that we can just merge as is. Than reviewing this will become faster. |
tomeon
force-pushed
the
github-actions-image-builds
branch
from
1e17cc7 to
dd66dfe
Compare
tomeon
force-pushed
the
github-actions-image-builds
branch
from
dd66dfe to
542e321
Compare
by s/-type/-xtype/ in the "find" invocation. Now nixos-generate prints both regular files and symlinks to regular files (like "run-nixos-vm" for the "vm" and "vm-nogui" formats).
Namely, assert that the last line of output refers to a store path that is a file or symlink to a file.
on nixpkgs versions prior to the commit that changed
config.system.build's type from a lazy attribute set to a submodule.
Prior to this type change, there is no system.build.kexec_tarball option
declared, so the NixOS module system does not resolve
priorities/overrides in the config.build.kexec_tarball definition.
That is, with lib.mkForce, the config.build.kexec_tarball definition
ends up being something like:
{
_type = "override";
content = <...>;
priority = 50;
}
Removing lib.mkForce allows us to successfully and sensibly interpolate
the value (== outPath) of system.build.kexec_tarball in
system.build.kexec_bundle's builder script.
Likewise, no lib.mkOverride for system.build.raw.
to gain access to proxmox-lxc and kubevirt profiles
that build various images. Limitation: checks only exist for
x86_64-linux and aarch64-linux.
Incidental changes:
1. Add nixos-21.11 release as a flake input.
2. Add the function `nixosGenerate'`, which is a generalized version
of `nixosGenerate` that takes the additional mandatory argument
`system` and the additional optional argument `nixpkgs` (the
latter of which should be a nixpkgs *flake*). This function is
used for constructing the flake checks; `nixpkgs` needs to be
parameterized in order to use both nixpkgs-unstable and
nixos-21.11.
tomeon
force-pushed
the
github-actions-image-builds
branch
from
542e321 to
a792c32
Compare
5 participants
Re this comment.
This PR introduces:
x86_64-linux(almost everything but thesd-aarch64andsd-aarch64-installerformats) andaarch64-linux(only thesd-aarch64andsd-aarch64-installerformats), andnixos-generatewith 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 🥲).