Skip to content

many: add bootc based manifest checksums#1821

Merged
ondrejbudai merged 7 commits into
osbuild:mainfrom
mvo5:gen-manifests-bootc-fake
Sep 12, 2025
Merged

many: add bootc based manifest checksums#1821
ondrejbudai merged 7 commits into
osbuild:mainfrom
mvo5:gen-manifests-bootc-fake

Conversation

@mvo5

@mvo5 mvo5 commented Sep 2, 2025

Copy link
Copy Markdown
Contributor

This PR adds manifest checksums for the bootc image types. This is useful to get manifest diffs and regression tests for bootc based manifest generation. Its slightly different from the regular distro based tests because we do not want to use real containers for speed reasons. So instead there is a new test/bootc-fake-containers.yaml that fakes the inputs we normally read from the container itself.

mvo5 added a commit to alexlarsson/osbuild-images that referenced this pull request Sep 3, 2025
This commit adds support for manifest generation with
build containers. The syntax is in gen-manifests-gen is
a bit ugly and uses a `#` to separate the main bootc
container and the build container. But this tool will
go away and get replaced with
osbuild#1821
which has a nicer syntax.
mvo5 added a commit to alexlarsson/osbuild-images that referenced this pull request Sep 3, 2025
This commit adds support for manifest generation with
build containers. The syntax is in gen-manifests-gen is
a bit ugly and uses a `#` to separate the main bootc
container and the build container. But this tool will
go away and get replaced with
osbuild#1821
which has a nicer syntax.
mvo5 added a commit to alexlarsson/osbuild-images that referenced this pull request Sep 3, 2025
This commit adds support for manifest generation with
build containers. The syntax is in gen-manifests-gen is
a bit ugly and uses a `#` to separate the main bootc
container and the build container. But this tool will
go away and get replaced with
osbuild#1821
which has a nicer syntax.
@achilleas-k
achilleas-k self-requested a review September 3, 2025 12:01
github-merge-queue Bot pushed a commit that referenced this pull request Sep 3, 2025
This commit adds support for manifest generation with
build containers. The syntax is in gen-manifests-gen is
a bit ugly and uses a `#` to separate the main bootc
container and the build container. But this tool will
go away and get replaced with
#1821
which has a nicer syntax.
@mvo5
mvo5 force-pushed the gen-manifests-bootc-fake branch 2 times, most recently from 1c17d32 to b3b409e Compare September 4, 2025 15:02
@mvo5
mvo5 marked this pull request as ready for review September 4, 2025 15:02
@mvo5
mvo5 requested a review from a team as a code owner September 4, 2025 15:02
@mvo5
mvo5 requested review from lzap and thozza and removed request for a team September 4, 2025 15:02
@mvo5
mvo5 force-pushed the gen-manifests-bootc-fake branch 2 times, most recently from 1f67733 to 8446e6b Compare September 5, 2025 09:19
@mvo5

mvo5 commented Sep 5, 2025

Copy link
Copy Markdown
Contributor Author

The ibcli test failure will fix itself once osbuild/image-builder-cli#294 is merged in ibcli. Its not specific to this PR but to the new images library.

@mvo5
mvo5 force-pushed the gen-manifests-bootc-fake branch from a56b29e to ad86fa2 Compare September 8, 2025 07:22
achilleas-k
achilleas-k previously approved these changes Sep 10, 2025

@achilleas-k achilleas-k left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This turned out pretty good. Thanks for all the work.

LGTM

We always have a local and running container with bib
so we can figure out the architecture for it. This is
useful for the bootc distro because with that we can
create the correct distro/arch/imagetypes combination.

Note that some images (like ubi9) do not show the
architecture when inspecting the image. So we need
a `podman exec uname -m` fallback for those.

Note also that it would be nice in the future to
inspect for multi arch images and actually populate
the bootc distro with the correct architectures. But
that is tricky as we currently introspect (run) each
container so we would have to download/run all the
distros just to do the inspection. This is generally
not possible (without qemu-user) and certainly not
practical.
The current gen-manifest behavior is to not catch
panics. In part this is nice as it gives the full
backtrace. But it also lacks lots of content as
the panic happens without knowing for what image
type. So instead just handle a panic like an error
and how the image type that paniced and the error.
Tiny cleanup to use the json.NewDecoder() instead of getting
all the data first and then passing it to json.Unmarshal().
This is a bit more efficient and also slightly shorter (and
more idiomatic).
This commit adds support to generate fake manifests for
bootc. This a bit different from how this work for rpm
based distros. There the distro/arch/imgtype/blueprint
is enough to fully describe an image. However in the
bootc world the container is inspected for various
inputs as well so we need a (fast) way to provide
the inputs from the inspection. We could build fake
containers but it would still be a bit on the slow
side. So instead we define a new
`test/bootc-fake-containers.yaml` that can be used
to create a bunch of fake bootc inputs as if those
are read from the image itself.

With that we can (re)use the normal `config-map.json`
mechanism to get all the "bootc-*" distros and apply
the customizations.

Note that this adds some (f)ugly:
```
bootc.NewBootcForTesting()
bootc.BootcDistro.SetBuildContainerForTesting()
```
this is unavoidable if we want to use this approach
for testing. We could move to this testing to the
`booctest` fake containers approach from
osbuild#1828

The downside is slightly slower fake image generation
and that we need to run this all as root because
we need "podman container mount" for the introspection
to work (this is a big downside as it will generate
root owned manifest checksums).
Now that have the ability to generate bootc checksums, include
them.
This commit adds support for build containers in the manifest
tests.
We need to filter out all bootc-* distros, they are "virtual"
and will not show up in "list-images" which is used to validate
known distros.

Without this the validation will fail with:
```
 Validating config file paths
OK: All config files found
Validating build configurations (distros, arches, image types)
1 ./configs/empty.json:
  distros: bootc-*
  arches: *
  image types: *
```
@mvo5

mvo5 commented Sep 11, 2025

Copy link
Copy Markdown
Contributor Author

Sorry, had to force-push because of conflicts in the config-map

@ondrejbudai ondrejbudai left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! One tiny observation inline, definitely a follow-up material if you want to bother with it.

return fsType, nil
}

func findContainerArchInspect(cntId, ref string) (string, error) {

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK the associated image always has an arch, I was able to retrieve the arch for ubi9 like this:

obudai@outland ~> podman ps
CONTAINER ID  IMAGE                                   COMMAND     CREATED             STATUS             PORTS       NAMES
2eaa8a5d582c  registry.access.redhat.com/ubi9:latest  /bin/bash   About a minute ago  Up About a minute              charming_dubinsky
obudai@outland ~> podman inspect -f '{{.Image}}' 2eaa8a5d582c
28fbac8f0a2b3ee82129b9feaae59d029a5eba93e5372002d2612d965979101a
obudai@outland ~> podman image inspect -f '{{.Architecture}}' 28fbac8f0a2b3ee82129b9feaae59d029a5eba93e5372002d2612d965979101a
arm64

Could be a tad cleaner than execing? Not sure. Alternatively, we can just always exec so there's just one codepath.

@ondrejbudai
ondrejbudai added this pull request to the merge queue Sep 12, 2025
Merged via the queue into osbuild:main with commit 5ccbcbd Sep 12, 2025
25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants