this looks like it is nontrivial to build locally now...
this looks like it is nontrivial to build locally now...
Bhere's an example of that post-workflow step NOT saving due to cache-hit https://github.com/ublue-os/akmods/actions/runs/13102055564/job/36551528729#step:17:2
Bthat IS the downside
MProbably can throw together a Justfile as part of the testing
Byeah, i do something like this already at work, and i use just file to prep a local cache which matches up like this
BI'd like to convert this to Just and clean it up a lot, but I felt it more important to move forward iteratively
Bless overall change makes it easier to grok the set of changes... I hope.
Myeah 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 images in the /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?
