chore(deps): update quay.io/bootc-devel/fedora-bootc-42-compose docker tag to fedora-42-updates-testing-20250605.0 (main)
See merge request fedora/bootc/base-images!196
chore(deps): update quay.io/bootc-devel/fedora-bootc-rawhide-compose docker tag to fedora-rawhide-20250605.n.0 (main)
See merge request fedora/bootc/base-images!197
An update of a compose image from a specific Fedora version
triggers at least 4 builds: 'minimal', 'minimal-plus', 'standard'
and 'iot'.
We usually have 2 compose images updates (Fedora 42 and Rawhide) per
day so up to 8 builds are triggered at the same time. As we don't seem
to have a lot of resources in the Konflux cluster this leads to
build failures because of timeouts (the default pipeline timeout is 1h).
This change tries to mitigate this until we get more resources in the
Konflux cluster.
Signed-off-by: Miguel Martín <mmartinv@redhat.com>
Grouping compose changes per Fedora version will allow
us to retrigger the builds separately in case of failure.
Signed-off-by: Miguel Martín <mmartinv@redhat.com>
According to the documentation 'build' can be used after 'major', 'minor'
and 'patch' have been already used and a fourth version part is needed.
On the other hand, it's only mandatory to use at least one of 'major',
'minor' or 'patch'.
We are using 'patch' and 'build' in compose-images so this change is
to make the versioning consistent among both projects.
Signed-off-by: Miguel Martín <mmartinv@redhat.com>
Right now, the expectation for adding unpackaged content in a custom
base image flow is to do it after the main compose. The problem however
is that sometimes you want that content to affect the main compose
itself, so doing it afterwards is not sufficient.
The primary use case for this is sysusers.d dropins where you need
to make sure that sysusers in scriptlets don't pick UIDs/GIDs already
reserved on target client systems.
One way to work around this is to synthesize an RPM that ships the
dropin, and then ensure that it somehow runs as early as possible in the
transaction. This is doable but obviously quite a hack.
Enable this instead by adding a generic `--add-dir` switch which then
just translates to `ostree-layers` in the override manifest.
The dnf equivalent would be to first install e.g. `filesystem` and
`setup`, add files to the rootfs, and then install all the other
packages.
See also discussions in https://github.com/coreos/rpm-ostree/pull/5354.
The `set -euo pipefail` shouldn't be controversial.
The `set -x` bit is more debatable because it makes
the output more verbose but I find it helpful right
now as I comb through all sorts of details as part of
https://github.com/coreos/fedora-coreos-tracker/issues/1861.
If we care about less verbose output, I'd prefer we keep `-x` but
switched to having rpm-ostree buffer postprocess output and only dump it
if it fails.
Remove 'baseBranches' configuration option as it's not allowed
within the regex customManager.
Fixes#59
Signed-off-by: Miguel Martín <mmartinv@redhat.com>
As far as I can tell --cachedir was used prior to bootc-base-imagectl
being introduced in c89b6f4. Let's add the --cachedir option to
bootc-base-imagectl, but we won't use it in our Containerfile yet
because we need to wait for [1] to land in an rpm-ostree release.
This is useful today for people hacking away locally.
[1] https://github.com/coreos/rpm-ostree/pull/5391