Nnot in a bad one
Bunderstood 
Jlol I woulda squashed
J"perfect in one go."
Bhonestly, i think its nice to see that stuff but the final will squash
but the final will squash
Timagine someone reading the commits later and that shows up. ahhahaha at least it shows the history of the changes and how you were feeling about the commit at the time LOL
Boh, i know what you mean... why don't you see the kernels fetched? because an earlier build successfully cached them already
Nyou should use more sobs in your ones
RNo - I'm meaning you're calling the cache action before making the kernels. But I guess the cache action saves the data in a post-workflow step?
Byes, that's how it works by default.
there's a way you can be more specific and "retrieve from cache" and "save to cache" but this seems fine
there's a way you can be more specific and "retrieve from cache" and "save to cache" but this seems fine
Mthis 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/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
