RFC: GitHub Action for GraalVM (GR-33015)

[fniephaus]

We are working on a setup-graalvm GitHub Action (GHA) to simplify setting up different versions and configurations of GraalVM. We would like to use this discussion to collect potential use cases and discuss possible features. Please feel free to comment below.

Potential Use Cases

• Build native images using GHA (also in combination with gradle/maven)
• Simplify testing setups (including oracle/graal and GraalVM languages)
• Run GraalVM languages as part of a GitHub workflow
• Deploy GraalVM distributions

Initial Features

• Sets $JAVA_HOME and $GRAALVM_HOME to the selected GraalVM build for the current platform
• Adds $GRAALVM_HOME/bin to $PATH so that gu and all installed components are directly accessible
• Allows GraalVM to be built from tip (slowdown expected)
• Supports Ubuntu/Windows/macOS on amd64 (aarch64 currently not officially supported by GHA)
• Installs dependencies for selected GraalVM components (e.g., msvc for Native Image on Windows or libssl for TruffleRuby) and runs post-install hooks

GitHub workflow example

steps:
- uses: actions/checkout@latest
- uses: graalvm/setup-graalvm@1.0
  with:
    version: '22.0.0'
    java-version: '11'
    components: native-image,R,llvm-toolchain

Options

• version: any GraalVM release (XX.YY.ZZ), latest for the latest release, or trunk for building from tip (maybe dev as a compromise to save some time?) Defaults to the latest release.
• java-version: 11 or 17 (8 and 16 supported for old releases). Defaults to latest support Java version.
• components: comma-separated list of GU components supported for the selected GraalVM version.
• github-token: token for communication with the GitHub API. If set to ${{ secrets.GITHUB_TOKEN }}, helps to reduce rate limiting issues.
• set-java-home: instructs the action to set $JAVA_HOME. Defaults to true.

Possible Future Features

• GHA does not officially support aarch64, but self-hosted workers can be based on aarch64 and there are emulation workflows (e.g., uraimo/run-on-arch-action, GraalVM-related example)
• We recommend using different build jobs but if there are use cases, provide a utility to switch between multiple versions within one build job (e.g., switch-graalvm "21.3.0-java11").
• Add support for Mandrel (releases should be relatively simple to support, building Mandrel from tip requires additional steps).

Note that GitHub Action workers already come with the latest JDK11-based GraalVM release.

[chrisseaton]

Some languages such as Ruby need a few system libraries or other components installed to be useful, so the Action should install those.

[fniephaus]

Good point, I added that to the list of features.

[eregon]

Actually, at least GH hosted runners, there is no need to install anything for truffleruby, and the truffleruby from https://github.com/ruby/setup-ruby is already recompiled against each OS-version's existing libssl.

[zakkak]

That sounds great @fniephaus

We would like to see an option for using Mandrel as well (I am willing to contribute the corresponding parts).

Something like:

steps:
- uses: actions/checkout@latest
- uses: graalvm/setup-graalvm@1.0
  with:
    version: '22.0.0'
    java-version: '11'
    distribution: 'mandrel'

• distribution would be optional and set to 'graalvm' by default
• components would be ignored in the case of the Mandrel distribution as it only provides native-image

[fniephaus]

Thanks, I'll add this to the list. It might not make it into the very first release but we'll keep this in mind.

[fniephaus]

setup-java supports a "distribution" key but it seems we would only add it for Mandrel support. Do you think it is reasonable to support Mandrel through the "version" key for now? We could reserve a namespace "mandrel-" and it could then be used like this: "version: mandrel-latest" or "version: mandrel-21.3.0.0-Final".

What do you think?

[zakkak]

That sounds good.

FTR this is now implemented in graalvm/setup-graalvm#1

I assume mandrel-trunk should then be used for Mandrel builds from source.

[borkdude]

Good to see that this is being worked on. FWIW, I've been using https://github.com/marketplace/actions/setup-graalvm-environment in some projects too. /cc @DeLaGuardo.

[ricardozanini]

I've been using @DeLaGuardo's action too, and it fills my needs. Maybe having an option to install the native-image automatically without requiring an extra step would be excellent.

[fniephaus]

Do you think a dedicate Native Image example in the action's README would be sufficient? All you'd have to do is to explicitly mention native-image in the list of components:

- uses: graalvm/setup-graalvm@1.0
  with:
    version: '22.0.0'
    java-version: '11'
    components: native-image

While it is a common use case, I'm not sure we want to special case it given that the above example is simple. Any other opinions?

[helpermethod]

The flag for installing the native-image command is mandatory for multiplatform builds, as otherwise you have to juggle with different shells (powershell, bash).

[fniephaus]

I'm not sure I understand your comment. Could you elaborate a bit please? Multi-platform builds across different build jobs I assume?

On Windows, we recommend using x64 Native Tools Command Prompt for Native Image and I'd say that's what workflows are supposed to use, too. Not yet sure how to spawn that best (e.g. via PowerShell, cmd, or bash). Any experience reports are welcome!

[ricardozanini]

Do you think a dedicate Native Image example in the action's README would be sufficient? All you'd have to do is to explicitly mention native-image in the list of components:

Definitely! Today what we have to do is to run a command to first install GraalVM and then another to install native-image. For example:

    steps:
      - uses: actions/checkout@v2

      - name: Set up GraalVM
        uses: DeLaGuardo/setup-graalvm@5.0
        with:
          graalvm: '21.3.0'
          java: 'java11'

      - name: Install native-image component
        run: gu install native-image

[fniephaus]

That's exactly what we will unify in the new GitHub action: it will have first class support for the GraalVM Updater. The user-provided list of components will be installed via gu. Only if you request a trunk build, the workflow will build all requested components from source. But the resulting GraalVM installation will conceptually be identical to a GraalVM base with gu components installed.

[helpermethod]

It would also bei nice if it would setup ilammy/msvc-dev-cmd@v1 on Windows automatically.

Something like https://github.com/helpermethod/graalvm-native-image-toolchain/blob/main/action.yml

[fniephaus]

Right, we'll have to do something like this to support Native Image builds on Windows. Thanks for mentioning ilammy/msvc-dev-cmd.

[lorenzleutgeb]

I'm very interested in an "official" setup action. Your initial feature set suggests that you would set JAVA_HOME. I'd like to ask for this to be opt-out, i.e. I want to be able to prevent the action from setting JAVA_HOME. The reason being that I would like to use OpenJDK as the main JDK and GraalVM via Gradle Toolchains.

Just for reference, the step that I currently use:

mkdir graalvm
wget -qO- 'https://github.com/graalvm/graalvm-ce-builds/releases/download/vm-21.3.0/graalvm-ce-java17-linux-amd64-21.3.0.tar.gz' | tar xzf - --strip-components=1 -C graalvm
./graalvm/bin/gu install native-image
echo "${PWD}/graalvm/bin" >> $GITHUB_PATH
echo "org.gradle.java.installations.paths=${PWD}/graalvm" >> gradle.properties

[fniephaus]

Thanks for your feedback. Do you use the default JAVA_HOME or do you set up a JDK manually anyway?
Of course, we could add an option to disable/enable setting JAVA_HOME and decide on the default. If JAVA_HOME is not set to the GraalVM installation, it might be harder to run Java apps and tests on GraalVM, which is probably a common use case for this action. So my feeling is still that the action should set JAVA_HOME by default, and there could be an option "set-java-home" (enabled by default, can be disabled explicitly).

Would that work for you? Any other thoughts on this?

[lorenzleutgeb]

Sure. In GitHub Actions I use the action https://github.com/actions/setup-java to set up Java (which also sets JAVA_HOME). In addition I would use the GraalVM action to set up GraalVM (in my case combined with Native Image).

Something along the lines of set-java-home: false is what I meant by "this to be opt-out". It's just easy to overlook that there are people that might actually prefer JAVA_HOME not to be set (I totally understand it to be the default of course), that's why I posted.

[fniephaus]

Noted, thanks!

[fniephaus]

Thanks for the feedback, everyone! We have released an initial version of the new GitHub Action for GraalVM at:
https://github.com/marketplace/actions/github-action-for-graalvm

Please feel free to give it a try and file any issues or feature requests at: https://github.com/graalvm/setup-graalvm/issues

[lorenzleutgeb]

Sweet, congratulations on the release! I migrated two repos successfully. 🎊

• lorenzleutgeb/atlas@2ae0265
• alpha-asp/Alpha@6366e79

[fniephaus]

Yay! Glad it's working for you!

[ricardozanini]

Same here: quarkiverse/quarkus-jackson-jq#18

It's working perfectly for now. My only concern is about the requirement of the GITHUB_TOKEN. Not sure if it will work if someone without permission in the repo opens a PR. I remember having issues with the token not being injected in the workflow in situations like that. Let's see. :)

[fniephaus]

My only concern is about the requirement of the `GITHUB_TOKEN. Not sure if it will work if someone without permission in the repo opens a PR.

The new GitHub Action for GraalVM works without setting github-token so it's not a hard requirement but more a recommendation. Nonetheless, I'd be curious to know what you find out. Please file an issue if you run into any problems!

[neomatrix369]

Nice one @fniephaus - provides great value to the community, I will share this with the community on social media!

[dainiusjocas]

Maybe it is worth including the musl toolchain for static image building on Linux?

[borkdude]

I run this script: https://github.com/babashka/babashka/blob/master/script/setup-musl
It doesn't take long, around 10 seconds or so. See this build under "setup native dev tools": https://app.circleci.com/pipelines/github/babashka/babashka/5182/workflows/f15715cd-d7fc-453a-ba7b-e924235d214e/jobs/25340

[dainiusjocas]

@fniephaus, this is the step in GH Actions https://github.com/dainiusjocas/lucene-grep/blob/e8b6dfd4adf2535b90f22845a0ecb53bcd857b06/.github/workflows/release.yml#L94
it just invokes this script https://github.com/dainiusjocas/lucene-grep/blob/main/script/setup-musl
In the last pipeline run, it took 14s.

[fniephaus]

Thanks! Here's a PR introducing a feature for enabling musl for static image building: graalvm/setup-graalvm#4.

[borkdude]

Awesome!

[fniephaus]

musl support has landed: graalvm/setup-graalvm@778131f.