Currently if we make changes to the changelogs we would only notice them
once they reach the stable branch. This is also consistent what we are
doing with stable and latest.
* chore(ci): add gh token to release generator
Seems we need to pass the token to gh cli in workflows too
https://github.com/ublue-os/aurora/actions/runs/29793388914/job/88563341082#step:7:13
* consistency
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* feat(ci): setup runner with containers policy
Currently for ublue-os/akmods and kinoite (not pinned by digest), we
verify them and pull them right after. We can't trust the authenticity
of those images, as the tag in the meantime could point to a different,
potentially compromised digest.
To avoid this, we set up our runner so that it will refuse to pull
anything from Universal Blue or quay.io/fedora-ostree-desktops without
first getting verified with the corresponding public key in our repo.
With this, we can completely get rid of our verify-container recipe and
benefit from the retry logic that is implemented in the podman pulls we
already do beforehand.
This would mean that local builds would no longer verify the pulled
images, as the policy is very likely not configured, but I don't think
that is super important.
* fix: install cosign in non-production builds
* chore: be explicit about secrets needed for image build
Instead of inheriting *all* the secrets we are only selectively giving
the called workflows access to the secrets we actually need. Currently
we only have one secret we use for image signing but in the future we
may want to have a separate testing key we use to sign testing builds
only made in PRs and things like that.
We may want to look into setting things up in a way so production keys
are only ever used when we push to ublue-os/aurora.
This also happens to make the experience a little bit nicer in new forks
as the workflow will fail right after the start when the SIGNING_SECRET
wasn't set, as opposed to when signing the image.
xref: https://github.com/ublue-os/aurora/issues/2528
* chore: remove secrets from generate-release parts
I don't know why this exists, we don't need our cosign key in this part
of the workflow.
We should not rely on external actions if this functionality exists in
official tools.
We are only running this step when it's a stable image build so ommiting
the make_latest thing is fine to my understanding.
xref: https://github.com/ublue-os/aurora/issues/2528
we haven't used this for over a year, might as well remove it.
This used to be needed in a time before we had renovate, before the
bluefin split, we build way less images now in general and also latest
and stable do not build from the main branch anymore.
* 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
* 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
