search

actions / setup-java

Set up your GitHub Actions workflow with a specific version of Java
MIT License
1.57k stars 746 forks source link

readme

Setup Java

Basic validation Validate Java e2e Validate cache

The setup-java action provides the following functionality for GitHub Actions runners:

This action allows you to work with Java and Scala projects.

V2 vs V1

Usage

Basic Configuration

Eclipse Temurin

steps:
- uses: actions/checkout@v4
- uses: actions/setup-java@v4
  with:
    distribution: 'temurin' # See 'Supported distributions' for available options
    java-version: '21'
- run: java HelloWorldApp.java

Azul Zulu OpenJDK

steps:
- uses: actions/checkout@v4
- uses: actions/setup-java@v4
  with:
    distribution: 'zulu' # See 'Supported distributions' for available options
    java-version: '21'
- run: java HelloWorldApp.java

Supported version syntax

The java-version input supports an exact version or a version range using SemVer notation:

Supported distributions

Currently, the following distributions are supported: Keyword Distribution Official site License
temurin Eclipse Temurin Link Link
zulu Azul Zulu OpenJDK Link Link
adopt or adopt-hotspot AdoptOpenJDK Hotspot Link Link
adopt-openj9 AdoptOpenJDK OpenJ9 Link Link
liberica Liberica JDK Link Link
microsoft Microsoft Build of OpenJDK Link Link
corretto Amazon Corretto Build of OpenJDK Link Link
semeru IBM Semeru Runtime Open Edition Link Link
oracle Oracle JDK Link Link
dragonwell Alibaba Dragonwell JDK Link Link
sapmachine SAP SapMachine JDK/JRE Link Link
graalvm Oracle GraalVM Link Link

NOTE: The different distributors can provide discrepant list of available versions / supported configurations. Please refer to the official documentation to see the list of supported versions.

NOTE: AdoptOpenJDK got moved to Eclipse Temurin and won't be updated anymore. It is highly recommended to migrate workflows from adopt and adopt-openj9, to temurin and semeru respectively, to keep receiving software and security updates. See more details in the Good-bye AdoptOpenJDK post.

NOTE: For Azul Zulu OpenJDK architectures x64 and arm64 are mapped to x86 / arm with proper hw_bitness.

Caching packages dependencies

The action has a built-in functionality for caching and restoring dependencies. It uses toolkit/cache under hood for caching dependencies but requires less configuration settings. Supported package managers are gradle, maven and sbt. The format of the used cache key is setup-java-${{ platform }}-${{ packageManager }}-${{ fileHash }}, where the hash is based on the following files:

When the option cache-dependency-path is specified, the hash is based on the matching file. This option supports wildcards and a list of file names, and is especially useful for monorepos.

The workflow output cache-hit is set to indicate if an exact match was found for the key as actions/cache does.

The cache input is optional, and caching is turned off by default.

Caching gradle dependencies

steps:
- uses: actions/checkout@v4
- uses: actions/setup-java@v4
  with:
    distribution: 'temurin'
    java-version: '21'
    cache: 'gradle'
    cache-dependency-path: | # optional
      sub-project/*.gradle*
      sub-project/**/gradle-wrapper.properties
- run: ./gradlew build --no-daemon

Caching maven dependencies

steps:
- uses: actions/checkout@v4
- uses: actions/setup-java@v4
  with:
    distribution: 'temurin'
    java-version: '21'
    cache: 'maven'
    cache-dependency-path: 'sub-project/pom.xml' # optional
- name: Build with Maven
  run: mvn -B package --file pom.xml

Caching sbt dependencies

steps:
- uses: actions/checkout@v4
- uses: actions/setup-java@v4
  with:
    distribution: 'temurin'
    java-version: '21'
    cache: 'sbt'
    cache-dependency-path: | # optional
      sub-project/build.sbt
      sub-project/project/build.properties
- name: Build with SBT
  run: sbt package

Cache segment restore timeout

Usually, cache gets downloaded in multiple segments of fixed sizes. Sometimes, a segment download gets stuck, which causes the workflow job to be stuck. The cache segment download timeout was introduced to solve this issue as it allows the segment download to get aborted and hence allows the job to proceed with a cache miss. The default value of the cache segment download timeout is set to 10 minutes and can be customized by specifying an environment variable named SEGMENT_DOWNLOAD_TIMEOUT_MINS with a timeout value in minutes.

env:
  SEGMENT_DOWNLOAD_TIMEOUT_MINS: '5'
steps:
- uses: actions/checkout@v4
- uses: actions/setup-java@v4
  with:
    distribution: 'temurin'
    java-version: '21'
    cache: 'gradle'
- run: ./gradlew build --no-daemon

Check latest

In the basic examples above, the check-latest flag defaults to false. When set to false, the action tries to first resolve a version of Java from the local tool cache on the runner. If unable to find a specific version in the cache, the action will download a version of Java. Use the default or set check-latest to false if you prefer a faster more consistent setup experience that prioritizes trying to use the cached versions at the expense of newer versions sometimes being available for download.

If check-latest is set to true, the action first checks if the cached version is the latest one. If the locally cached version is not the most up-to-date, the latest version of Java will be downloaded. Set check-latest to true if you want the most up-to-date version of Java to always be used. Setting check-latest to true has performance implications as downloading versions of Java is slower than using cached versions.

For Java distributions that are not cached on Hosted images, check-latest always behaves as true and downloads Java on-flight. Check out Hosted Tool Cache for more details about pre-cached Java versions.

steps:
- uses: actions/checkout@v4
- uses: actions/setup-java@v4
  with:
    distribution: 'temurin'
    java-version: '21'
    check-latest: true
- run: java HelloWorldApp.java

Testing against different Java versions

jobs:
  build:
    runs-on: ubuntu-20.04
    strategy:
      matrix:
        java: [ '8', '11', '17', '21' ]
    name: Java ${{ matrix.Java }} sample
    steps:
      - uses: actions/checkout@v4
      - name: Setup java
        uses: actions/setup-java@v4
        with:
          distribution: '<distribution>'
          java-version: ${{ matrix.java }}
      - run: java HelloWorldApp.java

Install multiple JDKs

All versions are added to the PATH. The last version will be used and available globally. Other Java versions can be accessed through env variables with such specification as 'JAVAHOME{{ MAJORVERSION }}{{ ARCHITECTURE }}'.

    steps:
      - uses: actions/setup-java@v4
        with:
          distribution: '<distribution>'
          java-version: |
            8
            11
            15

Using Maven Toolchains

In the example above multiple JDKs are installed for the same job. The result after the last JDK is installed is a Maven Toolchains declaration containing references to all three JDKs. The values for id, version, and vendor of the individual Toolchain entries are the given input values for distribution and java-version (vendor being the combination of ${distribution}_${java-version}) by default.

Advanced Configuration

License

The scripts and documentation in this project are released under the MIT License.

Contributions

Contributions are welcome! See Contributor's Guide