Akmods Refactor

Original message was deleted

M2•6/29/25, 8:29 PM

Starting a refactor of the akmods repo.

Goals:

Local Testing possible
Pathway to multiarch
Remove asus/surface

M2•6/29/25, 8:29 PM

@bsherman

bsherman•6/29/25, 8:29 PM

yep

bsherman•6/29/25, 8:29 PM

a key thing about the current build model...

bsherman•6/29/25, 8:33 PM

we fetch a given set of kernel RPMs and cache them in github cache

building locally, that's not an option, obviously...

so my thought is, if our Github workflow can mount the cache to a directory local to the akmods build, or even at a tmpdir location we can manage... we could emulate this with just, too

obviously we want fetch-kernel to be a just recipe
so, it should fetch-kernel into the local kernel-rpms/kernel-rpms/ dir
when just fetch-kerneljust fetch-kernel runs in github, that path gets cached/restored to the same path

but in local mode

running just build commonjust build common or just build zfsjust build zfs should depend on just fetch-kerneljust fetch-kernel having already run, and it could auto run if it hasn't, probably with a 5 second countdown similar to how just run-containerjust run-container will auto-build just build-containerjust build-container if needed

antheas•6/29/25, 8:33 PM

youre overthinking it

antheas•6/29/25, 8:33 PM

just need to make the containerfiles run locally

Robert•6/29/25, 8:34 PM

A key thing for me is decoupling each build workflow from eachother.
Building extra should not depend at all on common. It shouldn't be in the same workflow even.
This enables multi arch.

Aantheas just need to make the containerfiles run locally

bsherman•6/29/25, 8:34 PM

have you seen the Cayo build setup yet?

antheas•6/29/25, 8:35 PM

i dont know what that is

antheas•6/29/25, 8:35 PM

but i do know that on kernel-bazzite i can run a command and build it locally

bsherman•6/29/25, 8:35 PM

we'll be following some of the patterns there

antheas•6/29/25, 8:35 PM

with the same container

antheas•6/29/25, 8:36 PM

i cant test the upload stuff of the action

antheas•6/29/25, 8:36 PM

but i dont care that never fails

RRobert A key thing for me is decoupling each build workflow from eachother. Building ex...

M2•6/29/25, 9:40 PM

can you expand on this a bit more?

Robert•6/29/25, 9:45 PM

Let's take Bluefin LTS as an example.
1 workflow is for regular Centos Stream 10. Another separate workflow run is for dx Centos Stream 10. Another separate workflow would be for regular CentOS Stream 11.
Each of these workflows are for a single "image", and can fan out/in without needing to wait for unrelated builds.

So if we then apply that same thing to akmods, we would still have a reusable workflow, but that reusable workflow would be called by "akmods-common-41.yml" and "akmods-extra-42.yml" workflows.

Robert•6/29/25, 9:46 PM

Then when we added multi-arch to Bluefin LTS, it was as easy as adding fanning out in the reusable workflow, building, then fanning in to create the manifests

M2•6/29/25, 9:47 PM

so individual workflows instead of building a matrix?

Robert•6/29/25, 9:47 PM

Yeah. To put it simply

Robert•6/29/25, 9:47 PM

No complicated matrixes. The most complex we would have is for architectures, since they will be bundled into a single manifest at the end of the workflow

Robert•6/29/25, 9:58 PM

Another way to put it - each of these pages should show at most, a single "deployable unit" (something that can be pushed on its own while still being valuable).

M2•6/29/25, 10:00 PM

so what would that look like with our common, extra, nvidia{,-open}, zfs?

what is a "deployable" unit in this case?

M2•6/29/25, 10:00 PM

would we have a common workflow, extra workflow, zfs and so on?

Robert•6/29/25, 10:02 PM

Yeah. common-41 can be pushed without depending on extra-41, and is valuable being pushed on it's own since it can have a common package updated

M2•6/29/25, 10:02 PM

so we would have a workflow per

kernel_flavor and version?

M2•6/29/25, 10:02 PM

might need to write a script for generating all of those....

bsherman•6/29/25, 10:45 PM

Yeah that sounds messy. But if all the complex logic is the Justfile already i guess all those workflows would be super simple

M2•6/29/25, 10:47 PM

Yeah. Everything would be pretty simple.

Right now the reusable workflow is a beast

MM2 Yeah. Everything would be pretty simple. Right now the reusable workflow is a b...

bsherman•6/29/25, 10:47 PM

Yeah new simplicity is a given

M2•6/29/25, 10:48 PM

Since it's handling a lot of different code paths

bsherman•6/29/25, 10:48 PM

how do we want to proceed?

I’m feeling more urgency on cayo extensions than kmods refactoring. But we can divide and conquer, too.

Curious what you think about my comments about kernel caching

bsherman•6/29/25, 10:49 PM

I think we follow the new patterns from Cayo where useful.

bsherman•6/29/25, 10:49 PM

Oops stepping away for a few

M2•6/29/25, 10:49 PM

That's the plan. Going to cache to a local directory and then use --volume on the build call to put them into place

M2•6/29/25, 10:50 PM

We really need extensions in Cayo. We also really need to fix the kmods that get installed as well for the centOS build

MM2 Since it's handling a lot of different code paths

Robert•6/29/25, 10:54 PM

How so?

The reusable workflow could accept a "build-args" input that it passes through to the justfile. It can remove all logic from the reusable workflow, which is what Bluefin LTS does (except for the tags, which I hate).

M2•6/29/25, 10:54 PM

The current one

Robert•6/29/25, 10:54 PM

Oh yeah. I hate the current one too because of it

Robert•6/29/25, 10:55 PM

Moving to fully utilise workflow inputs would remove almost all logic from the reusable workflow

M2•6/29/25, 10:57 PM

https://github.com/ublue-os/cayo/blob/main/.github/workflows/build.yml

This is done with a matrix.

But I'm imagining that this could move to being inputs that then set environment variables for the build

Robert•6/29/25, 10:57 PM

Yeah. It's a super simple matrix right now, so an easy refactor later

M2•6/29/25, 10:58 PM

And right now I'm imagining variables for:

kernel_flavor
version
bazzite_tag
target

Robert•6/29/25, 10:59 PM

I'd argue no need for Bazzite tag. Just accept build args array or something

Robert•6/29/25, 11:00 PM

But yeah. Abstracting that stuff sounds good

M2•6/29/25, 11:01 PM

https://github.com/ublue-os/akmods/blob/main/.github/workflows/build-bazzite.yml

They use right now for what looks like some sort of webhook so I don't want that to go away

Robert•6/29/25, 11:01 PM

That doesn't actually work IIRC

M2•6/29/25, 11:01 PM

Robert•6/29/25, 11:01 PM

It was meant to run a build each time Antheas pushed a new kernel, but we didn't hook it up right

M2•6/29/25, 11:03 PM

So the only matrix ends up being platform with this model

Akmods Refactor

Similar Threads

Similar Threads

Similar Threads