-
Notifications
You must be signed in to change notification settings - Fork 31
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
build(oci): add config to allow building images for other archs #1352
Conversation
Test image available:
|
36dce79
to
8f25cd2
Compare
Test image available:
|
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.
Looks good. If Jib can't create manifest lists, we could add a podman step as part of the build or CI to create it using the image produced by Jib:
podman manifest create quay.io/cryostat/cryostat:2.3.0-snapshot containers-storage:quay.io/cryostat/cryostat:2.3.0-snapshot-linux-arm64
We would just need to make sure the tags for the manifest lists aren't already in use.
That makes sense. On each developer workstation there probably isn't much need to build multiarch and create a manifest image on a regular basis, so just doing it in CI before publishing the upstream builds should work well. I tried a setup with this: but ran into some hurdles with the |
8f25cd2
to
85a26d6
Compare
Test image available:
|
85a26d6
to
929b44b
Compare
Test image available:
|
929b44b
to
51525c1
Compare
Test image available:
|
The ARM64 image I built manually has been verified as working in the comments of https://github.com/cryostatio/cryostat/issues/1329 , so I'm picking this back up. @ebaron how do you think we should tag the published images? I'm thinking of reusing the old naming scheme for manifests, and then having the arch-specific images with the os/arch appended. So |
That should be fine, but do we need to publish the arch-specific images at their own tags? Would just the manifest be enough? |
The manifest looks like it's really just a manifest with no real image contents:
so I think the arch-specific images still would need to be published in some form or another, otherwise the manifest alone would be pointing at layer hashes that can't be found and pulled. |
Ah nevermind,
|
51525c1
to
2d259f2
Compare
Test image available:
|
2d259f2
to
3eb5690
Compare
Test image available:
|
3eb5690
to
4ea7876
Compare
Test image available:
|
4ea7876
to
45a21d3
Compare
45a21d3
to
1817c22
Compare
Test image available:
|
Welcome to Cryostat! 👋
Before contributing, make sure you have:
main
branch[chore, ci, docs, feat, fix, test]
git commit --amend --signoff
Related to #1329
Description of the change:
This adds some configuration to the
pom.xml
so that the build architecture (and OS, though this only makes sense to uselinux
now) can be changed by setting-Dbuild.arch=arm64
. This will cause the image build to pull the specified architecture for the UBI layer, and to build the application image for that specified architecture as well.qemu-user-static
(on Fedora, or equivalent package elsewhere) must be installed for this step to work, since part of building the application base image involves pulling the cross-arch UBI and running commands within it (ex.microdnf
), so this part must be emulated to prepare the image.Motivation for the change:
Once we can verify that these images work as expected on real ARM hardware, we can continue to publish these on push via CI alongside the existing
linux/amd64
images so that developers who may be running on ARM hardware can also run Cryostat. Or, Cryostat upstream releases could be used in production ARM environments.I expect/hope the CI setup will basically consist of adding one of these actions as a step:
qemu-user-static
on your workstation)and then invoking
mvn -Dbuild.arch=arm64 clean package ...
as usual.TODO figure if there's a nice way with the existing base image build andjib
plugin to do an image manifest, rather than creating separate tagged images for different archs.