Chunkah is actively maintained and the algorithm seems to be more stable
for the layer plan which results in smaller sizes for weekly updates
compared to rpm-ostree. Although it looks like daily updates are
slightly bigger for the time being.
In the future there may be a way to consume previous build manifests as
well to further shrink down image sizes.
I am not deleting the old build-chunked-oci code yet, to make this PR
easier to revert in case we have to.
Rpm-ostree is basically the only blocker for rootless CI, which is
generally what we should be doing, PolP and all that. Now we only need
root privileges for bootc install. Althought to keep this PR more simple
I will implement this later.
It seems like bootc install needs more space now, not sure exactly why
that happens but seems to be related due to pruned /sysroot.
xref https://github.com/ublue-os/aurora/issues/2324
Co-authored-by: inffy <10782843+inffy@users.noreply.github.com>
This label was previously created by the hhd/legacy-rechunker instead of
on the image build process. We are now using the build-chunked-oci and
in the near future chunkah which do not mess with the labels.
Our changelogs script expects this label to be present in order for the
commits since last release to show up.
fixes: https://github.com/ublue-os/aurora/issues/2338
* chore(ci): make latest images build after push
* update
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): add config for backporting PRs to stable branch
This will automatically create PRs to the stable branch when something
has been merged to main if the cherry-pick label is present.
Co-authored-by: inffy <10782843+inffy@users.noreply.github.com>
* configure git author for the bot
---------
Co-authored-by: inffy <10782843+inffy@users.noreply.github.com>
* 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
