-
Notifications
You must be signed in to change notification settings - Fork 78
bootc: add component tests based on fake containers (HMS-9296) #1828
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
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? |
|
otherwise, lgtm |
alexlarsson
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
8889d6f to
d8b6e5b
Compare
d8b6e5b to
c4f7820
Compare
4a905e6 to
5d3e245
Compare
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).
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).
5d3e245 to
75faf88
Compare
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).
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).
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"), | ||
| ) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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".
There was a problem hiding this comment.
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.
b537378 to
e3dbec8
Compare
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).
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).
8001f4b to
7d4cbf8
Compare
|
Looked OK, but is failing to find |
thozza
left a comment
There was a problem hiding this 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 ->
images/pkg/bib/container/container.go
Lines 67 to 75 in 49c3d90
| // 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) | |
| } | |
| } |
a4fc094
a4fc094 to
865bf2c
Compare
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.
865bf2c to
ece43b4
Compare
|
Closing as this is part of https://github.com/osbuild/images/pull/1848/commits which is about to get mered |
This commit introduces a fake bootc container that contains just enough os-release to work.
/jira-epic HMS-8839
JIRA: HMS-9296