Closed ciaranmcnulty closed 2 years ago
This does not yet quote work; it builds but at runtime gets this error:
java.lang.UnsatisfiedLinkError: no conscrypt_openjdk_jni-linux-aarch_64 in java.library.path
I think we need to ensure an ARM version of conscrypt is available
The conscrypt error is resolved in https://github.com/wiremock/wiremock/issues/1671
There's no reason this PR can't be merged, as it shouldn't change the behaviour on AMD64, but we won't be able to have working ARM64 builds until we try with a wiremock release with that change in
Confirmed image builds correctly with JAR from master
ARM is now supported : 6e062ef6418396997ba2d53e7111c1df8396af85
@rodolpheche I can see the GHA changes but have you made the equivalent of this change in the Dockerfile?
If not, have you had successful tested ARM builds? I think this change is needed.
(Mostly the GOSU version bump)
@ciaranmcnulty yes, multiarch build is made with Docker buildx in combination with QEMU. So, each version has its own gosu binary relative to the arch.
Now, you can see there are 3 digests for the main image : https://hub.docker.com/r/wiremock/wiremock/tags?page=1&name=main
That's great, it seems to execute fine. I'm not sure therefore why I had to bump the gosu version locally to make it work!
Just as an FYI the ARM builds won't work properly with HTTPS until the next wiremock release (see https://github.com/wiremock/wiremock/issues/1671) - you may want to hold off on tagging versions until this is released properly
(I just verified wiremock/wiremock:main
has this issue)
I'm aware of the issue related to conscrypt, I got some relative troubles with alpine image.
Next Docker image version will fix the issue
This is slightly cleaner than detecting using dpkg, but does require buildkit (or a default for the build argument in cases of non-buildkit builds)
This will also make multi-architecture builds simpler (see #44)