i386 is continiously failing to build
grooverdan opened this issue · 3 comments
https://doi-janky.infosiftr.net/job/multiarch/job/i386/job/websphere-liberty/
Step 19/24 : RUN if [ "$OPENJ9_SCC" = "true" ]; then populate_scc.sh; fi && rm -rf /output/messaging /output/resources/security /logs/* $WLP_OUTPUT_DIR/.classCache && chown -R 1001:0 /opt/ibm/wlp/output && chmod -R g+rwx /opt/ibm/wlp/output
---> Running in 1666241a73d1
Removing intermediate container 1666241a73d1
The command '/bin/sh -c if [ "$OPENJ9_SCC" = "true" ]; then populate_scc.sh; fi && rm -rf /output/messaging /output/resources/security /logs/* $WLP_OUTPUT_DIR/.classCache && chown -R 1001:0 /opt/ibm/wlp/output && chmod -R g+rwx /opt/ibm/wlp/output' returned a non-zero code: 1
So I assume its due to the populate_scc.sh script.
@ymanton The populate_scc.sh fails on i386, but only for WebSphere Liberty. Open Liberty is fine. Any idea why that would be? Thanks.
I assume it's because Open Liberty isn't actually being built on this platform since OpenJ9 doesn't have i386 Linux builds, where as WebSphere Liberty uses IBM JDK which does have i386 Linux builds.
The problem probably exists in both. I'll take a look.
populate_scc.sh was failing because 32-bit IBM JDKs don't support multi-layered SCCs. Without the multi-layered capability the SCC files will potentially be duplicated across Docker image layers and significantly increase the size of the final image, so I don't think we should build and distribute SCCs in 32-bit images. I've opened a PR to disable SCCs if the JVM pointed to by JAVA_HOME appears to be a 32-bit one.