Adds cross platform architecture compilation for native image

[kgston]

Closes #1443

This attempts to fill in the gap in cross platform architecture native image packaging. Added a new key graalVMNativeImagePlatformArch: Option[String] to specify the target platform architecture. Currently it only supports a single platform as doing multi platform would involve a much bigger change in the code base.

While this works technically, the performance is still rather lacking. When I crossed compiled (amd64 -> arm64) compile times took ~19x longer. The simple hello world test took over 5 minutes to produce a binary.

The 5+ minutes test case also triggered a bug in SBT #6771 causing the test to be aborted halfway through, but was recently fixed in SBT 1.9.3 hence the upgrade. However that then necessitated an upgrade in Scala to 2.12.13. Also updated the tests to use the --no-fallback option as I noticed that it was generating a fallback image when running the tests.

Also, it was a little tricky to correctly detect if an existing container was in the correct platform architecture when graalVMNativeImagePlatformArch is not defined. I used a docker image label to get around that.

Also added support for newer graalvm containers using a different package name.

[lightbend-cla-validator]

Hi @kgston,

Thank you for your contribution! We really value the time you've taken to put this together.

We see that you have signed the Lightbend Contributors License Agreement before, however, the CLA has changed since you last signed it. Please review the new CLA and sign it before we proceed with reviewing this pull request:

https://www.lightbend.com/contribute/cla

[kgston]

The CI checks seems to be unhappy that I added a new parameter for specifying the target platform architecture.

[kgston]

@muuki88 Could you take a look at the PR when you find the time? Thanks.

[muuki88]

The CI checks seems to be unhappy that I added a new parameter for specifying the target platform architecture.

IIRC there's another, private trait where those parameters can be added. If not, I'm fine with adding those binary compatibility breakages to the mima exceptions.

[kgston]

The CI checks seems to be unhappy that I added a new parameter for specifying the target platform architecture.

IIRC there's another, private trait where those parameters can be added. If not, I'm fine with adding those binary compatibility breakages to the mima exceptions.

Hmm, I don't know if its exactly breaking binary compatibility since the old parameters still work the same as the old versions. According to the CI, it just says that the new param that I added doesn't exist on the older version, which is to be expected.

Is there a better, more appropriate way to specify the target platform?

[muuki88]

I'm referencing this validation error: https://github.com/sbt/sbt-native-packager/actions/runs/5718905995/job/15495686495#step:7:1

which indicates binary compatibility issues. What are you referencing to?

[kgston]

I've fixed the binary compat issue and all the subsequent issues that popped up from the graalvm test. Other unrelated tests are failing, and I assume it is a side effect from upgrading SBT. I'll try to debug the issue when I find some time, but taking a quick look at the github action logs, it is not immediately obvious what's the issue. Any hints would be appreciated, otherwise I might have to create a separate PR for upgrading to SBT 1.9.3 to try and isolate the issue.

[muuki88]

triggered a rerun .. the appveyor thing seems super weird.

Do the tests fail on your local machine?

[kgston]

I tried running validateDebian, validateDocker and validateWindows on master branch and I do get the same errors as with on the Github Actions too.. So it might be unrelated to the SBT 1.9.3 upgrade after all? 🤷‍♂️