Fedora 42 is GA now so use GA repos. This is the legacy Pungi path, but
one should be able to test the legacy paths locally too.
Pungi overrides repos so it doesn't hit this.
chore(deps): update quay.io/bootc-devel/fedora-bootc-42-compose docker tag to fedora-42-updates-testing-20250606.0 (main)
See merge request fedora/bootc/base-images!199
chore(deps): update quay.io/bootc-devel/fedora-bootc-rawhide-compose docker tag to fedora-rawhide-20250609.n.0 (main)
See merge request fedora/bootc/base-images!200
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>
