MCurrent thought process for the akmods/kcache merge
Going to use artifacts to upload an oci to github. Then pull that down for the actual kmods portion.
Common and Extra get tagged with convenience tag.
ZFS/Nvidia only get tagged with kernel version
Then, going to keep using the kcache package names as well as the akmods name
Going to use artifacts to upload an oci to github. Then pull that down for the actual kmods portion.
Common and Extra get tagged with convenience tag.
ZFS/Nvidia only get tagged with kernel version
Then, going to keep using the kcache package names as well as the akmods name
Mkcache package name will have common akmods since that should be smallest
Bat work, i've been recently using GH caches with small OCI images for build acceleration... so whether using GH artifacts or GH cache, the idea is similar and would be great
Ballows pulling down those kernel packages once per kernel variant...
and then using them in the kmod builds
and then using them in the kmod builds
Bbut we could take it a step further to speed up the overall build process...
we could, again for each kernel variant...
prep the build environment in an oci image (eg, the
cache/artifact that
and then each kmod could spin off as a distinct matrix job and use that prepped build env... and when they finish, they store their results as artifacts
after they all finish, a job collects all the artifacts, including the kernel cache, and assembles the final OCI image
we could, again for each kernel variant...
prep the build environment in an oci image (eg, the
build-prep.sh step)cache/artifact that
and then each kmod could spin off as a distinct matrix job and use that prepped build env... and when they finish, they store their results as artifacts
after they all finish, a job collects all the artifacts, including the kernel cache, and assembles the final OCI image
Bit'll use a bunch of builders... but... it'll run pretty fast
MBeside the startup time and upload/download, this seems pretty reasonable
Bexcept for nvidia and ZFS, probably most of those builds are less than 2 minutes
MFor those two, I believe we should not tag them with Fedora Version and only tag explicitly with kernel-version.
MNvidia is a bit complicated given that we are dependent as well on repos so us caching them may not always be perfect.
Bpart of me just wants to simplify this stuff to a simpler set of images ... eg
and for whatever kernel is specified, it has everything:
kernel-cache:KERNEL_VERSION_VARIANT_NAME and for whatever kernel is specified, it has everything:
- kernel rpms
- common kmod rpms
- nvidia rpms
- if a bazzite/extra image, the extras rpms
- if a coreos kernel, the ZFS rpms
MWe still need an easy access for Fedora Version since we won't know linux version immediately
Mbut.... I like the idea of consolidating down completely
AVery bad idea for each akmod to matrix
AEach builder has 4 cores and you're not saturating them already
AYou'll just burn builders if you do that and the spin up time is not worth jt
AYou need to do the matrix in builder
AAs in dnf install all the deps
AFrom all akmods
AAnd then build them in parallel
AWith something like gnu parallel
AMe thinks that you could do one build for bazzite and one for others
AAnd the bazzite one would spit all the akmods for bazzite
ASo rebuild extra
MI'm actually starting to lean this way.
Part of me is thinking that uploading an artifacts will break PRs so I'm going to look into charting out the following:
common:
Part of me is thinking that uploading an artifacts will break PRs so I'm going to look into charting out the following:
kernel-cache:<variant_name>-<fedora_version>-{common,extra} kernel-cache:<variant_name>-<kernel_version>-{common,extra}common:
- kernel
- common-kmods
- nvidia
- zfs (if coreos variant)
- kernel
- common-kmods
- nvidia
- zfs (if coreos variant)
- extra-kmods
Mso for main/bluefin it would be
bazzite:
podman pull kernel-cache:coreos-stable-41-commonbazzite:
podman pull kernel-cache:bazzite-41-extraMinternal structure:
/rpms/{kernel,kmods,nvidia,zfs}MMBuilding only two images per kernel also means doing the artifact upload would only be slightly beneficial so just doing it inside of the common, extra workflow would likely be sufficient.
MAlso, I think I'm going to move some of the workflow bash to a just file to make local building a bit easier.
MProgress moving forward. Kernel-cache is now a justfile.
Working on akmods. Looking into the source for akmodsbuild, it will compile using all available cores.
https://src.fedoraproject.org/rpms/akmods/blob/rawhide/f/akmodsbuild#_34
But overall this is progressing.
Working on akmods. Looking into the source for akmodsbuild, it will compile using all available cores.
https://src.fedoraproject.org/rpms/akmods/blob/rawhide/f/akmodsbuild#_34
But overall this is progressing.
Ashouldnt akmods the command build in parallel already?
MAkmods for compiling the kmod from the srpm should max out jobs to number of threads available.
Additionally akmods and dnf both use lock files to prevent parallel calls so we are limited to the akmods jobs
Additionally akmods and dnf both use lock files to prevent parallel calls so we are limited to the akmods jobs
Adnf is ok
Aone dnf call with all akmods
Abut what about the akmod command? is that single threaded?
Makmod command calls akmodsbuild which then sets jobs to number of threads
Awhat im seeing is
Athat installing all akmods to the container
Athen calling akmod rebuild is all you need
Aand you can drop all .sh scripts
Athen you just sign and rename in one step and push
Mhttps://github.com/ublue-os/akmods/blob/0f236b66a933858e482a9ab2ed07e1bd0aed3f4b/build-kmod-nvidia.sh#L26
It sounds like you don't want these lines and instead just use one akmods call at the end. That really won't change things since the akmods script will just iterate through each kmod that needs to be built one at a time
https://src.fedoraproject.org/rpms/akmods/blob/rawhide/f/akmods#_454
But will continue to poke around to see if we can speed this up somehow.
I could see maybe running multiple container builds on one host at the same time might help a little for going through the smaller kmods.
It sounds like you don't want these lines and instead just use one akmods call at the end. That really won't change things since the akmods script will just iterate through each kmod that needs to be built one at a time
https://src.fedoraproject.org/rpms/akmods/blob/rawhide/f/akmods#_454
But will continue to poke around to see if we can speed this up somehow.
I could see maybe running multiple container builds on one host at the same time might help a little for going through the smaller kmods.
GitHub
A caching layer for pre-built Fedora akmod RPMs. Contribute to ublue-os/akmods development by creating an account on GitHub.
AAkmods shouldn't take that long to compile
AEspecially the small ones
AHave you checked how long it takes on e.g fedora workstation to dk all of them?
AForking that script and parallelizi g that code part is more than trivial
