Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Auto detect JVM toolchains in standard locations on GitHub runners #561

Closed
JavierSegoviaCordoba opened this issue Jan 8, 2023 · 2 comments · Fixed by #855
Closed

Auto detect JVM toolchains in standard locations on GitHub runners #561

JavierSegoviaCordoba opened this issue Jan 8, 2023 · 2 comments · Fixed by #855
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@JavierSegoviaCordoba
Copy link

The issue on the Gradle repo: gradle/gradle#14903

Current workaround:

      - name: Create Gradle files
        run: |
          cd ~
          mkdir -p .gradle/ && touch .gradle/gradle.properties

      - name: Set up Java
        id: setup-java
        uses: actions/setup-java@v3
        with:
          distribution: 'zulu'
          java-version: 11

      - name: Setup Gradle Java installations paths
        run: |
          cd ~/.gradle
          echo "org.gradle.java.installations.paths=${{ steps.setup-java.outputs.path }}" >> gradle.properties

      - name: Setup Gradle
        uses: gradle/gradle-build-action@v2
@bigdaz bigdaz changed the title Auto detect JVM toolchains Auto detect JVM toolchains in standard locations on GitHub runners Feb 18, 2023
@bigdaz bigdaz added the enhancement New feature or request label Feb 18, 2023
@joffrey-bion
Copy link

joffrey-bion commented Aug 11, 2023

Given that it's less easy to get the output from setup-java by default in the gradle-build-action, I think a good starting point would be to at least make Gradle aware of the pre-installed Java distributions through this action.

GitHub currently provides all current LTS versions in the hosted tools cache, and it provides env variables to each of their locations, based on the major version. At the time of writing, those are: JAVA_HOME_8_X64, JAVA_HOME_11_X64, and JAVA_HOME_17_X64 (see the runner environment doc).

So I believe a good starting point would be for this action to pass by default a CLI argument that makes Gradle aware of those env variables, such as:

-Porg.gradle.java.installations.fromEnv=JAVA_HOME_8_X64,JAVA_HOME_11_X64,JAVA_HOME_17_X64

This has the drawback of ignoring this property from the project's gradle.properties, so we could mitigate this by providing an option to disable this behaviour. WDYT?

@bigdaz
Copy link
Member

bigdaz commented Aug 20, 2023

It turns out this was mostly working out of the box.

On all runners, toolchains provisioned via setup-java are added to the Maven Toolchains definition, and Gradle will detect based on this information.

On ubuntu-latest and `macos-latest' the pre-installed JDKs are symlinked into standard locations, and so are detected by Gradle.

But on windows-latest the pre-installed JDKs are not detected.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants