yeah i think being tied first to github actions is fine given that we are relying on the cache actio
yeah i think being tied first to github actions is fine given that we are relying on the cache action
B@p5 here's where the cache was last saved: https://github.com/ublue-os/akmods/actions/runs/13101891946/job/36551158340#step:17:1
Bright, but we could still move most of the bits into Just recipes for a local build option and then change the workflows to call those same recipes
again, I consider that future improvement which would further delay progress
again, I consider that future improvement which would further delay progress
MSecureboot check only happens if no hit on the kernel. That's smart
Byeah, the cache-hit check feels quite powerful, if we are confident in the cache, we can speed things up but also be confident we're re-using the same artifacts
Mwe should probably remove the --mount=type=cache,dst=/var/cache/dnf from the containerfiles
RHow close are we to the 10GB cache limit in that repo? I have no idea how large kernels are 
Mthe current cached rpms are usually about 200 MBs
MSurface is slightly larger but we could probably remove the additional cached packages from them
J@ssweeny we ever migrate that repo over?
SBoth of my akmods repos are migrated
Jok removing your temp org membership, thank you for flying universal blue airlines
Mhttps://github.com/actions/cache?tab=readme-ov-file#cache-limits
So it's 10 GB and gets evicted after not being used for a week.
The kernel rpms end up in each container?
So it's 10 GB and gets evicted after not being used for a week.
The kernel rpms end up in each container?
BBread the docs 
yes all kernel RPMs end up in each akmods image at
yes all kernel RPMs end up in each akmods image at
/kernel-rpms/
Awhat are you caching?
BAwhy do we cache the kernel?
A10gb means 10 kernels?
Ais that right?
Ano we have 6 kernels
Aballpark 8 kernels?
Acan the kernel cache be used to rollback?
BI think the question would be answered by looking at the PR.
But the github kernel cache is an internal implementation detail for builds.
The only end state change is to include the Kernel RPMs (currently in
But the github kernel cache is an internal implementation detail for builds.
The only end state change is to include the Kernel RPMs (currently in
kernel-cache images) in the akmods/kernel-rpms/ directory.Aim looking at it and cant tell
Ai tend to no
Aso, whats the point of the cache?
Ai like the grouping
Awow the cache takes 2 seconds?
MDon't download the RPMs everyday and make sure all of the packages are built from same kernel version
M2 seconds vs 4 minutes
Aim seeing 20 seconds?
Ain any case, implementation detail no rollbacks
Acan you make an action that takes a bazzite kernel version, defaulting to latest, and builds that kernel?
Awe can also webhook that
Bthe best case cache hit is a bit faster/slower depending on method used to lookup latest available kernel version
Bit varies for kernel flavors
Ayeah bazzite kernel is instant
Bi'm sure we can, that's not in scope for the current PR
Adef not
BAlets merge this first
Acan you make one of the actions push the image to kernel-cache?
Aso its not breaking?
Aa breaking change*
Aalso @Kyle Gospo maybe do a testing build before this merges, i want that kun akmod
Bi cover that in the PR description
steps will be:
0) complete approval of PR
1) merge this PR
2) convert downstreams (bazzite/bluefin/aurora) to use this and not use kernel-cache image
3) archive kernel-cache repo
merging this should be non breaking
steps will be:
0) complete approval of PR
1) merge this PR
2) convert downstreams (bazzite/bluefin/aurora) to use this and not use kernel-cache image
3) archive kernel-cache repo
merging this should be non breaking
Aso kcache keeps existing
Auntil the change happens
Bit WOULD open up the chance of kernel-cache and akmods being out of sync, however
Byes
