J(jk)
Nthat button looks appealing right
RHow does this work? I couldn't see any podman push or artifact upload steps after building the kernels, so how are these used by the akmods?
Tclosed wontfix
Bi mean, it builds green
Nthe commit msgs are hilarious
Bfirst stage of workflow caches Kernel RPMs using a github cache... then the second stage is basically the old akmods process, except using the github cached artifacts rather than OCI images...
in the end, the kernel RPMs are added to
in the end, the kernel RPMs are added to
/kernel-rpms within the akmods images
Mthis is a community project.
Bthat's how you know this had a lot of TLC 
Ni mean it in a good way :D
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 squashTimagine 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?
