GraalVM native image test

[eed3si9n]

This is inspired by scala/bug#12116, which was surprising to me.

Given that some projects (Coursier, scalafmt, sbt etc) are adopting GraalVM native image, could we add native image building to the Community Builds process to prevent regressions?

The setup examples could be found by looking into the CI setup of the projects that uses GraalVM:

• scalafmt - https://github.com/scalameta/scalafmt/blob/v2.6.4/bin/build-native-image.sh
• sbtn - https://github.com/sbt/sbt/blob/d3ffd33e1755beecbd1c75e06b7efa7ecb8f9eb4/.appveyor.yml#L39-L42

[SethTisue]

I'm game, but also, I haven't studied GraalVM at all — others on the team and elsewhere at Lightbend have.

Regardless of where the GraalVM knowhow comes from: if we decide that the community build is the right place for this, I'd be happy to handle the install-GraalVM-on-the-Jenkins-workers and integrate-with-dbuild-as-appropriate angles.

[SethTisue]

if we decide that the community build is the right place for this

to unpack that a bit:

is there any need/advantage to involving dbuild here?

even if there isn't, it can be convenient to do something in the community build context anyway just because we have existing infrastructure (both technical and social) for running and maintaining the community build

but also, perhaps it could be a separate thing that would either become part of PR validation, or would run nightly-ish by some other means, perhaps via Travis-CI (or GitHub Actions)

presumably if it were a standalone thing it wouldn't be a big, slow, hungry beast like the community build, which we're more or less forced to self-host because it's such a monster

[eed3si9n]

Yea. I meant Community Build broadly as a regular checking process. The actual job runner can be anything.

It just needs to keep track of some list of community projects, freeze commit ID, swap out the Scala version with the nightly, and run some build tasks. Since it's only a few projects, a Bash script should be able to do that.

[SethTisue]

It just needs to keep track of some list of community projects

Is there a clear need to involve community code and not just the stuff inside scala/scala itself?

[eed3si9n]

Is there a clear need to involve community code and not just the stuff inside scala/scala itself?

I think so, for practical reasons. The way this test would run, I imagine, is that you take an existing JVM program, and then tell native-image to build a native image, similar to an end-of-world linker.

This could be a hello world application, but that would only test println(...). So you want to maximize the coverage. If we can make a native image out of unit tests or something that's great, but not all code can be turned into native-image for various restrictions. Thus, picking community projects like scalafmt or sbtn could be used as a shortcut since they've done the work of using currently-GraalVM-compat parts of Scala.

[SethTisue]

I guess I was imagining running a subset of partests (a subset to be determined initially probably by just running all of them and seeing which ones fail). Your suggestion seems plausible as well.

[SethTisue]

Is there an interested volunteer who would like to tackle this? I would suggest that the testing be done on Travis-CI, in a new, separate job. It would be welcome even just to have a job that did a little basic smoke testing, for possible later expansion.

[dwijnand]

Running native-image is much slower than "just" compiling or running tests. I'm not sure exactly but I feel like it's in the 5x or more area. So I think this should be a new cron job, rather than an additional, parallel job of our existing setup.