The `if os.path.isdir(args.manifest)` bit dates from the introduction
of this script, but doesn't really work. I suspect the intent here was
to abstract over some manifests being top-level YAML files and others
being directories).
Except that:
1. The script didn't actually check the right path. It's checking
`$PWD/{args.manifest}` instead of `$MANIFESTDIR/{args.manifest}`.
2. `list` doesn't have the equivalent logic to look for `manifest.yaml`
files in subdirectories.
3. Nowadays, there is both a e.g. `standard.yaml` _and_ a
`standard/manifest.yaml` directory. The established semantic there
AIUI is that the top-level manifests are opinionated for a specific
OS (Fedora/CentOS/RHEL), whereas the directories are shared across
all of those.
So let's just nuke support for the directory path.
It's confusing right now how the manifest names differ across
fedora-bootc, centos-bootc and rhel-bootc. Both rhel-bootc and
centos-bootc only use "bare" names like `minimal`, and `standard`, while
fedora-bootc prefixes everything with `fedora-`.
For FCOS/SCOS/RHCOS, it would be beneficial to maintain the same naming
across all of those.
Let's just match the naming here to the "bare" version. But add symlinks
so that we don't break the old names (but note that being symlinks, they
will no longer show up in `bootc-base-imagectl list`).
chore(deps): update quay.io/bootc-devel/fedora-bootc-42-compose docker tag to fedora-42-updates-testing-20250617.0 (main)
See merge request fedora/bootc/base-images!211
chore(deps): update quay.io/bootc-devel/fedora-bootc-42-compose docker tag to fedora-42-updates-testing-20250613.0 (main)
See merge request fedora/bootc/base-images!208
chore(deps): update quay.io/bootc-devel/fedora-bootc-42-compose docker tag to fedora-42-updates-testing-20250612.0 (main)
See merge request fedora/bootc/base-images!207
chore(deps): update quay.io/bootc-devel/fedora-bootc-42-compose docker tag to fedora-42-updates-testing-20250610.0 (main)
See merge request fedora/bootc/base-images!204
chore(deps): update quay.io/bootc-devel/fedora-bootc-rawhide-compose docker tag to fedora-rawhide-20250610.n.0 (main)
See merge request fedora/bootc/base-images!205
Right now, one can't use the official fedora-bootc images for the custom
base image flow because it doesn't actually ship `bootc-base-imagectl`.
This will be fixed by the move to Konflux, but it's not clear when that
will happen.
Given how trivial it is to do, let's just ship it in the image for now.
Closes: https://gitlab.com/fedora/bootc/base-images/-/issues/44
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.
