* feat(ci): package cache with OCI artifacts
We are hitting a couple limitations in regards to actions/cache [1] with
our new testing branch workflow, as we previously relied on scheduled
builds from the main branch, which we no longer do with this model.
Now we make new cache on merge_group on the first build on Sundays, I
chose Sundays just because. Which means we run only a single build with
no cache per week and use that same build to generate a new fresh cache.
Else we would end up with 3 versions of vscode in our cache.
There is no point uploading cache on *every* PR.
For simplicity sake this has no handling/differentiation for our stable
and main branch. When we bump the fedora version of our main/testing
images then the cache for stable will just get stale.
We are mixing root/rootless usage of oras/cosign, I made it use root or
else we will get premission issues.
[1]: https://github.com/actions/cache/issues/1537
fixes: https://github.com/ublue-os/aurora/issues/2351
* define blessed day
* chore: remove command -v prefixes
not needed, running everything rootless now
* feat(ci): rootless CI
26.04 runners use sudo-rs, which does not support this flag. It doesn't
seem to have broken too much, Only thing I could see is the github token
not being passed to the build.
```
sudo: preserving the entire environment is not supported, '-E' is ignored
```
So this is a good time to move over to a rootless CI I guess.
* chore: unset target-dir for container-storage-action
This defaults to the user container storage
If you specified --kernel-pin from cli it will now correctly verify and
donwload the right version (instead of the newest one), if it's
specified in the Justfile and CLI then CLI wins.
The pin that is always set to an empty string would override it.
taken from blue-build[1], this also happens to make updates smaller by
100MB. Might fix the following issues like [2] and [3]. I could not
reproduce these issues myself and just using chunkah made it possible
for me to overlay firefox with rpm-ostree.
[1]: b6f36bd9a2
[2]: https://github.com/ublue-os/aurora/issues/2209
[3]: https://github.com/ublue-os/aurora/issues/2492
Co-authored-by: Daniel Hast <32797673+HastD@users.noreply.github.com>
* refactor(ci): initial work for using flag/arg-based workflow
The goal of this is to make the buildsystem function like any other CLI
program. The only recipes I haven't touched in this PR are the very
simple recipes like verify-container, retag-nvidia-ghcr and
login-registry. In the future I want to split up this Justfile in
multiple smaller ones where it feels right to do that.
resolves: https://github.com/ublue-os/aurora/issues/2436
* document minimum just version
* build recipe
* feat: redo the way we do kernel pins
This allows an independent pinning of kernels for future ARM builds
regardless of x86. Probably the way we should have done it from the
beginning.
* get rid of build-ghcr and build-pipeline related things
We are not using the build-pipeline recipe anywhere right now. I think a
build-rechunk recipe is good enough for now.
I think build-ghcr doesn't make any sense anymore as it's now just a
single additional flag. The rechunk recipe with chunkah currently
doesn't alter any behavior when run in ghcr so we can delete this. But
this will likely change when chunkah implements some form of passing a
previous manifest.
I want to do a recipe at some point which replaces the general idea of
the pipeline recipe and is as close to github as possible. Build ->
Rechunk -> Secureboot-> tag + push an image to a local registry bootc
install.
* do deprecated build-chunked-oci recipe
* remove build-pipeline parts of ostree-rechunk
* export oci
* load rootful recipe
currently not used in CI as we are running everything as root.
* secureboot
* generate-point
* gen-sbom
* package cache
* bootc install
* some remaining shebangs
best practice to use env bash here instead
* push recipe
* redo generate-build-tags and tag-images
I removed the version input here. This has been broken for probably a
very long time, this didn't do anything for months at least, oldest log
I could find here:
```
Error: no such object: "aurora:latest"
Tags for this Action...
latest latest-43.20260424 latest-20260424 43 43-43.20260424 43-20260424
```
Kernel input is now done through just, so no reason to pass that, no
idea why we had that here in the first place.
* fix kernel pin for build-rechunk
This convenience recipe needs to take all the options from the build one
This is probably the way we should be doing it instead of having a
separate pull, also works for the other images, mainly useful for akmods
and kinoite as we do not pin those by a digest. Which we should be doing
at some point.
In the future we probably want to have some kind of mechanism that
ensures that we are only pulling the blessed verified image (configuring
the runner environment with a policy).
Currently we are verifying the tag and then pulling the image a short
while later. This is not very likely to happen but leaves a couple
seconds of room where an untrusted image could be published that we
did not verify the authenticity of.
This ties a little bit into [1].
[1]: https://github.com/ublue-os/aurora/issues/2381
* chore: Revert "chore: delete bootc install config (#1568)"
This is one of the things we need for bcvk to work with our images.
This reverts commit 5f76360321.
* chore: drop filesystem option for bootc install
