* feat(ci): testing stream
* feat(ci): workaround for scheduled stable build on non-default branch
* feat(renovate): initial config for testing stream
We want to get builds that are triggered by kinoite updates from
renovate but promote changes like get-aurora-dev/common and
ublue-os/brew from main to the stable branch, while still receiving
updates for things like github actions.
This is probably the right way to handle the differentiation of PR and
production runs instead of doing it via the not a pull request
condition.
Co-authored-by: inffy <10782843+inffy@users.noreply.github.com>
This takes 1min to run but is more reliable than the
container-storage-action in some cases on runners with only 20GB of
available disk space on /. We correctly mount /mnt to
/var/lib/containers via the container-storage-action when we have low
space available but we are running out of space on /var/tmp, which this
action does not address, this usually happens on the COMMIT step of the
image build.
Observed here: [1]
[1]:
https://github.com/ublue-os/aurora/actions/runs/26897102965/job/79339038302
This causes certain characters to not be displayed properly, on my
system this was the case for system applications like dolphin and
konsole as well as flatpak applications like firefox and discord.
for example: 처형박수
This was originally introduced in [1] because of [2].
I'm not 100% sure if this doesn't break something else, but I tested
this by setting Steam (Flatpak) to chinese and I didn't see any
misrendered characters like described in [3]. It seems like this got
resolved at some point by something(?)
[1]: https://github.com/ublue-os/main/pull/334
[2]: https://bugzilla.redhat.com/show_bug.cgi?id=2188765
[3]: https://github.com/ValveSoftware/steam-for-linux/issues/9418
Currently we are tagging these:
```
latest
latest-44.20260531
latest-20260531
latest-44
44-44.20260531
44-20260531
```
and this PR will add:
```
latest-44.20260531.2
latest-20260531.2
44-44.20260531.2
44-20260531.2
```
and for stable:
```
stable
stable-44.20260531
stable-20260531
stable-daily
44.20260531
stable-daily-44.20260531
stable-daily-20260531
```
```
stable-44.20260531.1
stable-20260531.1
stable-daily-44.20260531.1
stable-daily-20260531.1
```
Today there has been no stable image released so it starts out with .1
but there has been a single latest image, so it bumps it to .2
Very much inspired by ublue-os/main's solution [1], but this
implementation has a bug where where it will find the first "missing"
POINT (not the highest!) in the tags.
This would falsely choose the wrong POINT in the case we delete a bad
image and there is a "gap".
For example, we have the images .1-3 already on the registry, then
delete .2 and this implementation would correctly choose the next image
as .4 (instead of .2) as it's not just a dumb while loop.
This is very much an edge case and makes the jq command quite cursed but
I think this should always be reliable.
This feature has been broken previously because we didn't tag the image
with an index point number so no matter how many images we have built
that day, it was always .1 in the various VESRION fields in os-release.
fixes: https://github.com/ublue-os/aurora/issues/1833
[1]: ef33e7ca96/Justfile (L239-L251)
The ubuntu 26.04 provided version is still too old, recently they
stabilized the --fmt flag [1]. This is consistent with the other
invokations and also allows us to have some whitespace between variable
definitions for example as they seemed to have changed that.
[1]: 21b3833bf0
* fix(ci): push production tags after signing
If the signing step fails, causes for this can be ghcr jank or a
sigstore outage and not testing our changes properly beforehand. Then we
have already pushed images to the registry with production tags that
users can update to.
The clients won't actually update to these images as we enforce
verification on the client side to pull images from ghcr.io/ublue-os/
only with a valid signature attached. Otherwise this leads to an "update
failed" on the users POV, which is very confusing. This has been a
longstanding issue across the org [1] [2] [3].
To workaround this, we push a tag to the registry first that we don't
care about and clients don't check against for updates. I chose the job
id because it always changes.
This also happens to get rid of the action we use for retries to
workaround ghcr jank, we were forced to do this in the past because the
old podman version we used at the time didn't have those features.
Using podman to push signatures and images at the same time is not
something that is viable at the moment unfortunately but is definitely
the approach we should be using once it works well.
This effort can be seen at [4]. Although we are likely hitting [5] here
where all layers get invalidated because of this bug. We are effectively
pushing full images/no shared layers every time we do podman push. Which
causes the overall push step in CI to take upwards of 20 minutes.
fixes: https://github.com/ublue-os/aurora/issues/2135
[1]: https://github.com/ublue-os/bazzite/pull/4902
[2]: https://github.com/ublue-os/main/issues/643
[3]: https://github.com/ublue-os/bazzite/issues/3044
[4]: https://github.com/containers/podman/issues/27796
[5]: https://github.com/ublue-os/aurora/pull/2199
Signed-off-by: renner <renner0@posteo.de>
* fix: cosign verify
It seems like cosign tries to verify all .sig files on the registry for
that digest, one of which is generated by cosign sign with a static key
and one is generated by actions/attest using an OIDC.
This exactly broke, which is what we have been using for the longest
time:
```
cosign verify --key cosign.pub ghcr.io/ublue-os/aurora:latest
Error: no matching attestations: expected key signature, not certificate
error during command execution: no matching attestations: expected key
signature, not certificate
```
And this currently works to verify the image, although it is of course
not the same thing as singing with the ublue cosign key.
This will not work going forward after this commit:
```
cosign verify \
--certificate-oidc-issuer https://token.actions.githubusercontent.com \
--certificate-identity-regexp="github.com/ublue-os/aurora/.github/workflows/*" \
ghcr.io/ublue-os/aurora:latest
```
Signed-off-by: renner <renner0@posteo.de>
* feat: use staging for the temporary tag
This is just a minor cosmetic thing and recudes the amount of tags we
have because it's static and not changing unlike the run id.
Signed-off-by: renner <renner0@posteo.de>
* fix: use empty string by default for temporary tag
Signed-off-by: renner <renner0@posteo.de>
* fix: don't use signing config
Or else we are getting this error with new cosign 3.X.X
```
Error: must provide --new-bundle-format or --bundle where applicable
with --signing-config or --use-signing-config error during command
```
Signed-off-by: renner <renner0@posteo.de>
* chore: bump cosign-installer to v4.1.2
* chore: move oras install to beginning as well
if this fails at the beginning because of jank then it's not so bad
* fix(ci): make sbom signing work
```
Error: error getting signing config from TUF: error setting TUF options:
error setting TUF mirror: error reading remote.json: open
/home/runner/.sigstore/root/remote.json: permission denied
```
---------
Signed-off-by: renner <renner0@posteo.de>
* feat(ci): stop building stable-daily images
These do not make super much sense, this is in preparation for the
testing branches so we don't build too many images.
We will still build stable images in PRs to find out if things are
broken on those images only.
To not break existing users, point this to `:stable` instead,
effectively lying about the cadence now. We have to do it this way
because stable-daily has ZFS and `:latest` doesn't to avoid breaking
that use case. In the future when we have removed ZFS we can point this
to `:latest`.
* fix: only publish :stable on schedule
We do not want to publish stable on every PR merge
---------
Co-authored-by: inffy <10782843+inffy@users.noreply.github.com>
There have been quite a couple changes in the last couple years that
were bootloader related in Fedora, namely switching to bootupd [1] with
F41 which allows updating the bootloader. Maybe this happenend to
resolve the issue because it got changed to fedora at some point?
Originally needed because fwupd looks for EFI/our_ID/**.
The only change we make to our package is hardcoding efi_os_dir=fedora
with a build option.
New installs have the directory set to fedora.
Introduced in 78671f2.
I have no idea if we still need this, this is a scream test.
[1]: https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd
