When you make a PR to aurora on a Sunday before the daily renovate bump
kicked off (POINT=1) (before 4AM UTC) then this run would not have any
cache.
PRs always should have cache.
* 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>
The libdnf5 package owns various files under /usr/lib/sysimage/libdnf5
that are getting generated during the build, for instance, the
transaction history (dnf history list), which changes with every build
due to timestamps and package versions.
This means that every single image build has a unique libdnf5 package,
which results in every update unnecessarily downloading it, although
nothing that we care about changed.
dnf history is not useful here; you can look in the build logs if you
really wanted to see what transactions are being done. On the client
side, things like dnf history undo don't work or are largely not the
right tool for the job in custom image builds.
xref: https://github.com/ublue-os/aurora/issues/2579
* 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.
