Skip to content

Conversation

@mvo5
Copy link
Contributor

@mvo5 mvo5 commented Sep 3, 2025

This commit introduces a fake bootc container that contains just enough os-release to work.

/jira-epic HMS-8839

JIRA: HMS-9296

@alexlarsson
Copy link
Contributor

Can you also add some checks that the customization directories (like /usr/lib/bootc-image-builder) are copied from the target image to the build pipeline?

@alexlarsson
Copy link
Contributor

otherwise, lgtm

alexlarsson
alexlarsson previously approved these changes Sep 3, 2025
Copy link
Contributor

@alexlarsson alexlarsson left a comment

Choose a reason for hiding this comment

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

lgtm

achilleas-k
achilleas-k previously approved these changes Sep 3, 2025
@mvo5 mvo5 dismissed stale reviews from achilleas-k and alexlarsson via 8889d6f September 3, 2025 15:57
@mvo5 mvo5 force-pushed the bootc-build-imgref-test branch 2 times, most recently from 8889d6f to d8b6e5b Compare September 4, 2025 08:36
@mvo5 mvo5 force-pushed the bootc-build-imgref-test branch from d8b6e5b to c4f7820 Compare September 4, 2025 11:10
@mvo5 mvo5 changed the title bootc: add real container tests based on alpine bootc: add component tests based on fake containers Sep 4, 2025
@mvo5 mvo5 marked this pull request as ready for review September 4, 2025 11:11
@mvo5 mvo5 requested a review from a team as a code owner September 4, 2025 11:11
@mvo5 mvo5 requested review from lzap, supakeen and thozza and removed request for a team September 4, 2025 11:11
@mvo5 mvo5 force-pushed the bootc-build-imgref-test branch 2 times, most recently from 4a905e6 to 5d3e245 Compare September 4, 2025 14:07
mvo5 added a commit to mvo5/images that referenced this pull request Sep 4, 2025
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).
mvo5 added a commit to mvo5/images that referenced this pull request Sep 4, 2025
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).
@mvo5 mvo5 force-pushed the bootc-build-imgref-test branch from 5d3e245 to 75faf88 Compare September 4, 2025 15:11
mvo5 added a commit to mvo5/images that referenced this pull request Sep 5, 2025
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).
mvo5 added a commit to mvo5/images that referenced this pull request Sep 5, 2025
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).
@schutzbot schutzbot changed the title bootc: add component tests based on fake containers bootc: add component tests based on fake containers (HMS-9296) Sep 5, 2025
mvo5 added a commit to mvo5/images that referenced this pull request Sep 8, 2025
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).
"go", "build",
"-o", fakeBootcPath,
filepath.Join(currentDir, "./exe"),
)
Copy link
Contributor

Choose a reason for hiding this comment

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

This seems a bit weird to me, as opposed to building it from say the Makefile and just doing a copy here. But I guess it works.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, a makefile will probably make this a lot simpler, let me give it a quick stab.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I added it as its own commit so if people dislike it its easy to revert.

Copy link
Contributor

Choose a reason for hiding this comment

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

Hmm, i was hoping rather that there was a way to actually set up the dependencies so that "go test" would itself, build the required separate file first. However, that doesn't seem possible.

I dunno if shelling out to make is better or not. It seems easier to maintain and read to me, but I agree Makefiles are not very "go-like".

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Lets see what the others think, I like it for the same reasons as you (maintain/read) but have no super strong preference.

@mvo5 mvo5 force-pushed the bootc-build-imgref-test branch from b537378 to e3dbec8 Compare September 8, 2025 08:32
mvo5 added a commit to mvo5/images that referenced this pull request Sep 11, 2025
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).
github-merge-queue bot pushed a commit that referenced this pull request Sep 12, 2025
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
#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).
@mvo5 mvo5 force-pushed the bootc-build-imgref-test branch from 8001f4b to 7d4cbf8 Compare September 12, 2025 11:59
alexlarsson
alexlarsson previously approved these changes Sep 12, 2025
supakeen
supakeen previously approved these changes Sep 15, 2025
@supakeen supakeen added this pull request to the merge queue Sep 15, 2025
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Sep 15, 2025
@supakeen supakeen added this pull request to the merge queue Sep 15, 2025
@supakeen
Copy link
Member

Looked OK, but is failing to find uname?

@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Sep 15, 2025
thozza
thozza previously approved these changes Sep 15, 2025
Copy link
Member

@thozza thozza left a comment

Choose a reason for hiding this comment

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

LGTM, but as Simon pointed out, the test fails on uname. The relevant code seems to be the container Arch detection ->

// not all containers set {{.Architecture}} so fallback
c.arch, err = findContainerArchInspect(c.id, ref)
if err != nil {
var err2 error
c.arch, err2 = findContainerArchUname(c.id, ref)
if err2 != nil {
return nil, errors.Join(err, err2)
}
}

@mvo5 mvo5 dismissed stale reviews from thozza, supakeen, and alexlarsson via a4fc094 September 15, 2025 15:00
@mvo5 mvo5 force-pushed the bootc-build-imgref-test branch 2 times, most recently from a4fc094 to 865bf2c Compare September 15, 2025 15:21
This commit introduces a fake bootc container that contains
just enough content to simulate a bootc image. It is based
on a "FROM scartch" container and does not require a network
connection. It will build a static go binary to provide the
"sleep" binary and the "bootc" binary that is expected by
the bootc introspection code in images.

The code to geneate fake bootc containers is put into
pkg/distro/bootc/bootctest
and can potentially be reused for manifest tests and
for ibcli/bib.

Thanks to Alex for suggesting the static go binary.
This switches from the go code to build the fake bootc/sleep
binary to a Makefile. Its probably easier to read this way
(I say probably as Makefiles are not that big in the go world
but then the Makefile is a lot more concise).

Thanks to Alex for suggesting this.
This commit tweaks the way the architecuture is detected
for the bib containers. Instead of looking at the running
container config for the architecture and then trying
`uname -m` as fallback look for the container image and
then inspect that for the architecture. This seems to
be the most reliable way and work with the bib test
containers and with the ubi9 containers.
@supakeen supakeen force-pushed the bootc-build-imgref-test branch from 865bf2c to ece43b4 Compare September 15, 2025 17:05
@mvo5
Copy link
Contributor Author

mvo5 commented Sep 16, 2025

Closing as this is part of https://github.com/osbuild/images/pull/1848/commits which is about to get mered

@mvo5 mvo5 closed this Sep 16, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants