joschi / setup-jdk

(DEPRECATED) Set up your GitHub Actions workflow with a specific version of AdoptOpenJDK

🚨 Notice

The joschi/setup-jdk GitHub Action is deprecated.

Please consider switching to the official actions/setup-java action v2 or later which also supports AdoptOpenJDK and its successor Eclipse Temurin:

https://github.com/actions/setup-java/tree/v2.5.0#basic

In order to migrate to actions/setup-java it is sufficient to replace the name of the action and set the distribution parameter to temurin.

Before:

steps:
- uses: actions/checkout@v2
- uses: joschi/setup-jdk@v2
  with:
    java-version: '11' # The OpenJDK version to make available on the path
    architecture: 'x64' # defaults to 'x64'
- run: java -cp java HelloWorldApp

After:

steps:
- uses: actions/checkout@v2
- uses: actions/setup-java@v3
  with:
    distribution: 'temurin' # See 'Supported distributions' for available options
    java-version: '11'
    architecture: 'x64' # defaults to 'x64'
- run: java -cp java HelloWorldApp

setup-jdk

This action sets up a Java development environment with the OpenJDK distribution from AdoptOpenJDK for use in actions by:

• Downloading and caching a version of the OpenJDK by version and adding to PATH. Downloads from AdoptOpenJDK.
• Registering problem matchers for error output.

The action is based on actions/setup-java and is using the AdoptOpenJDK API for fetching the JDK binaries.

Usage

See action.yml

Basic

steps:
- uses: actions/checkout@v2
- uses: joschi/setup-jdk@v2
  with:
    java-version: '11' # The OpenJDK version to make available on the path
    architecture: 'x64' # defaults to 'x64'
- run: java -cp java HelloWorldApp

Examples of version specifications that the java-version parameter will accept:

• A major Java version

  e.g. 6, 7, 8, 9, 10, 11, 12, 13, ...

Local file

steps:
- uses: actions/checkout@v2
- uses: joschi/setup-jdk@v2
  with:
    java-version: '4.0.0'
    architecture: x64
    jdkFile: <path to jdkFile> # Optional - jdkFile to install java from. Useful for versions not found on Zulu Community CDN
- run: java -cp java HelloWorldApp

Matrix Testing

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        java: [ '8', '11', '13' ]
    name: Java ${{ matrix.java }} sample
    steps:
      - uses: actions/checkout@v2
      - name: Setup java
        uses: joschi/setup-jdk@v2
        with:
          java-version: ${{ matrix.java }}
          architecture: x64
      - run: java -cp java HelloWorldApp

Publishing using Apache Maven

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Set up JDK 1.8
      uses: joschi/setup-jdk@v2
      with:
        java-version: '8'

    - name: Build with Maven
      run: mvn -B package --file pom.xml

    - name: Publish to GitHub Packages Apache Maven
      run: mvn deploy
      env:
        GITHUB_TOKEN: ${{ github.token }} # GITHUB_TOKEN is the default env for the password

    - name: Set up Apache Maven Central
      uses: joschi/setup-jdk@v2
      with: # running setup-jdk again overwrites the settings.xml
        java-version: '8'
        server-id: maven # Value of the distributionManagement/repository/id field of the pom.xml
        server-username: MAVEN_USERNAME # env variable for username in deploy
        server-password: MAVEN_CENTRAL_TOKEN # env variable for token in deploy
        gpg-private-key: ${{ secrets.MAVEN_GPG_PRIVATE_KEY }} # Value of the GPG private key to import
        gpg-passphrase: MAVEN_GPG_PASSPHRASE # env variable for GPG private key passphrase

    - name: Publish to Apache Maven Central
      run: mvn deploy
      env:
        MAVEN_USERNAME: maven_username123
        MAVEN_CENTRAL_TOKEN: ${{ secrets.MAVEN_CENTRAL_TOKEN }}
        MAVEN_GPG_PASSPHRASE: ${{ secrets.MAVEN_GPG_PASSPHRASE }}

The two settings.xml files created from the above example look like the following.

settings.xml file created for the first deploy to GitHub Packages

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
  <servers>
    <server>
      <id>github</id>
      <username>${env.GITHUB_ACTOR}</username>
      <password>${env.GITHUB_TOKEN}</password>
    </server>
    <server>
      <id>gpg.passphrase</id>
      <passphrase>${env.GPG_PASSPHRASE}</passphrase>
    </server>
  </servers>
</settings>

settings.xml file created for the second deploy to Apache Maven Central

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 https://maven.apache.org/xsd/settings-1.0.0.xsd">
  <servers>
    <server>
      <id>maven</id>
      <username>${env.MAVEN_USERNAME}</username>
      <password>${env.MAVEN_CENTRAL_TOKEN}</password>
    </server>
    <server>
      <id>gpg.passphrase</id>
      <passphrase>${env.MAVEN_GPG_PASSPHRASE}</passphrase>
    </server>
  </servers>
</settings>

NOTE: The settings.xml file is created in the Actions $HOME directory. If you have an existing settings.xml file at that location, it will be overwritten. See below for using the settings-path to change your settings.xml file location.

If you don't want to overwrite the settings.xml file, you can set overwrite-settings: false.

If gpg-private-key input is provided, the private key will be written to a file in the runner's temp directory, the private key file will be imported into the GPG keychain, and then the file will be promptly removed before proceeding with the rest of the setup process. A cleanup step will remove the imported private key from the GPG keychain after the job completes regardless of the job status. This ensures that the private key is no longer accessible on self-hosted runners and cannot "leak" between jobs (hosted runners are always clean instances).

See the help docs on Publishing a Package for more information on the pom.xml file.

Publishing using Gradle

jobs:

  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2

    - name: Set up JDK 1.8
      uses: joschi/setup-jdk@v2

    - name: Build with Gradle
      run: gradle build

    - name: Publish to GitHub Packages
      run: gradle publish
      env:
        USERNAME: ${{ github.actor }}
        PASSWORD: ${{ secrets.GITHUB_TOKEN }}

NOTE: The USERNAME and PASSWORD need to correspond to the credentials environment variables used in the publishing section of your build.gradle.

See the help docs on Publishing a Package with Gradle for more information on the build.gradle configuration file.

Apache Maven with a settings path

When using an Actions self-hosted runner with multiple shared runners the default $HOME directory can be shared by a number runners at the same time which could overwrite existing settings file. Setting the settings-path variable allows you to choose a unique location for your settings file.

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Set up JDK 1.8 for Shared Runner
      uses: joschi/setup-jdk@v2
      with:
        java-version: '8'
        server-id: github # Value of the distributionManagement/repository/id field of the pom.xml
        settings-path: ${{ github.workspace }} # location for the settings.xml file

    - name: Build with Maven
      run: mvn -B package --file pom.xml

    - name: Publish to GitHub Packages Apache Maven
      run: mvn deploy -s $GITHUB_WORKSPACE/settings.xml
      env:
        GITHUB_TOKEN: ${{ github.token }}

License

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

Contributions

Contributions are welcome! See Contributor's Guide

setup-jdk's Issues

Sporadic HTTP 403 responses, but only on Mac OS

For some reason, our actions often fail spuriously with the following output:

Run joschi/setup-jdk@v2
  with:
    java-version: [1](https://github.com/qbicc/qbicc/runs/6614106260?check_suite_focus=true#step:3:1)7
    architecture: x64
    release_type: ga
    java-package: jdk
    openjdk_impl: hotspot
    heap_size: normal
    release: latest
    server-id: github
    server-username: GITHUB_ACTOR
    server-password: GITHUB_TOKEN
  env:
    CC: gcc
    LLVM_PATH: /Users/runner/work/_temp/llvm-install
    LD_LIBRARY_PATH: /Users/runner/work/_temp/llvm-install/lib:
    DYLD_LIBRARY_PATH: /Users/runner/work/_temp/llvm-install/lib:
Error: Unexpected HTTP response: 40[3](https://github.com/qbicc/qbicc/runs/6614106260?check_suite_focus=true#step:3:3)

I would think that this is an infrastructure problem, however it only happens with this action, and only on Mac OS.

Adoptium Temurin?

AdoptOpenJDK is basically history, although they say:

For a limited period of time we will augment the current AdoptOpenJDK API to serve binaries built from the Eclipse Adoptium community (Hotspot builds) and IBM (OpenJ9 builds). When you ask the current AdoptOpenJDK API for the latest ‘hotspot’ build by ‘adoptopenjdk’ we will serve you the latest Temurin build, and when you ask for the ‘openj9’ build by ‘adoptopenjdk’ we will serve you the IBM build. The licenses and content of these builds are unchanged. Although arguably that behavior is incorrect for the query, we think that is what most people would expect to get during the transition.

https://blog.adoptopenjdk.net/2021/08/goodbye-adoptopenjdk-hello-adoptium/

So I guess it's time to switch over to (or add) https://adoptium.net/

fails with 404

Run joschi/[email protected]
  with:
    java-version: openjdk14
    release_type: ga
    java-package: jdk
    openjdk_impl: hotspot
    architecture: x64
    heap_size: normal
    release: latest
##[error]Unexpected HTTP response: 404

joschi/[email protected] fails, joschi/setup-jdk@v1 works

Create an architecture alias for x86

Using x32 as the architecture for what is traditionally called x86 is an AdoptOpenJDK specific weirdness. Since this action is specific for AdoptOpenJDK this is fine, but allowing x86 would keep it more sane and more "drop-in" to actions/setup-java.

Avoid updating settings.xml

My runners are self-hosted and run on k8s pods, the settings.xml is mounted r/o through a config-map - hence the update of settings.xml fails. Could you add an option to opt-out of updating settings.xml please?