During a fresh checkout, I noticed that master is still around.

When Java package is added to the cache it is added using the package version. For example 8.0.181. When a Java package is looked up in the tool cache the version supplied by the user is used. That could be either 8 or 1.8. Both should match 8.0.181, but as you can expect tc.find won't match 1.8.

Should be downloadable e.g. from https://adoptopenjdk.net/

This is my pom.xml

    <version>1.4.8</version>

    <distributionManagement>
        <repository>
            <id>github</id>
            <name>GitHub Packages</name>
            <url>https://maven.pkg.github.com/sblantipodi/firefly_luciferin</url>
        </repository>
    </distributionManagement>

this my workflow:

      - name: Set up JDK 14
        uses: actions/setup-java@v1
        with:
          java-version: '15.x.x'
      - name: Publish package
        run: mvn -B deploy
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

maven deploy fails with a 422 error. can you help me please?

Error:  Failed to execute goal org.apache.maven.plugins:maven-deploy-plugin:2.8.2:deploy (default-deploy) on project FireflyLuciferin: Failed to deploy artifacts: Could not transfer artifact org.dpsoftware:FireflyLuciferin:jar:1.4.9 from/to github (https://maven.pkg.github.com/sblantipodi/firefly_luciferin): Transfer failed for https://maven.pkg.github.com/sblantipodi/firefly_luciferin/org/dpsoftware/FireflyLuciferin/1.4.9/FireflyLuciferin-1.4.9.jar 422 Unprocessable Entity -> [Help 1]

Releasing artifacts to Maven Central requires publishers to sign all of the assets with GPG. Publishers most commonly deal with this by utilizing maven-gpg-plugin.

This is a bit of a headache right now in GitHub actions as you have to create a step in your workflow that:

1. takes a GitHub secret containing your private key and writes it to a file:
   echo $GPG_PRIVATE_KEY > private.asc
2. imports the gpg key:
   gpg --import --batch private.asc

And to utilize the GPG key, you then have to pass it in as a maven argument:
-Dgpg.passphrase=$GPG_PASSPHRASE

This is definitely workable (see link for an example workflow) but it's more tedious than needed. It's also not ideal to pass passwords around using the command line even though GitHub Actions sanitizes them. Since setup-java already creates a settings.xml file that is preconfigured to publish to Maven Central, it would be nice if gpg could also be added to the settings.xml file.

The usage would look something like the following:

- name: Set up Apache Maven Central
  uses: actions/setup-java@v1
  with: # running setup-java again overwrites the settings.xml
     java-version: 1.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.GPG_PRIVATE_KEY }} # gpg private key to import
     gpg-passphrase: GPG_PASSPHRASE # env variable for gpg signing in deploy
- name: Publish to Apache Maven Central
  run: mvn deploy 
  env:
    MAVEN_USERNAME: maven_username123
    MAVEN_CENTRAL_TOKEN: ${{ secrets.MAVEN_CENTRAL_TOKEN }}
    GPG_PASSPHRASE: ${{ secrets.GPG_PASSPHRASE }}

And the generated settings.xml would look something like:

<servers>
    <server>
      <id>maven</id>
      <username>${env.MAVEN_USERNAME}</username>
      <password>${env.MAVEN_CENTRAL_TOKEN}</password>
    </server>
    <profiles>
      <profile>
        <activation>
          <activeByDefault>true</activeByDefault>
        </activation>
        <properties>
          <gpg.passphrase>${env.GPG_PASSPHRASE}</gpg.passphrase>
        </properties>
      </profile>
    <profiles>
</servers>

Since gpg is not supported by setup-java, other developers have had to step in to fill the void. samuelmeuli/action-maven-publish was created specifically to fill this gap but it overrides the settings.xml file to do so. It would better if the official setup-java action supported this, especially as some developers/organizations are uncomfortable with third-party actions.

I'm using this github action to setup Java for a non-java application that uses JNI and I'm getting the following error:

error while loading shared libraries: libjvm.so

Is it possible to (perhaps optionally) add this library to LD_LIBRARY_PATH? Additionally, on Windows it should be PATH.

This action can automatically configure gpg key if we set:

        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

But it is not clear for me what MAVEN_GPG_PRIVATE_KEY secret should contain. I have generated a gpg key in my local machine but how should I export it to be valid?
Maybe we can add a note in the readme?

thanks

This issue will track the progress of the v2 version of setup-java.

One of the core goals of the v2 version is to support downloading different distributions of Java. Currently Zulu builds of OpenJDK are downloaded and installed but with v2 we will be adding support for adoptOpenJDK builds of OpenJDK as well. Because this is a major change, a v2 major update is warranted.

One of the main goals of v2 is also to make setup-java extensible so that other distributions can be supported as well.

Major TODO items:

• Create ADR that outlines and documents the roadmap and plan for the v2 version: #97
• Accept ADR after getting feedback from the community
• Create v2-preview branch
• Implement all the necessary changes and merge them into the v2-preview branch
• Gather feedback and test using the v2-preview branch
• After being comfortable with the v2-preview changes, merge the branch into main
• Update public docs, and starter workflow to use v2 instead of v1 tags

Hi, I am getting an error when running the setup-java step in the following configuration:

    - uses: actions/setup-java@v1
      with:
        java-version: '12.x'

The error I get is the following:

Run actions/setup-java@v1
/bin/tar xzC /home/runner/work/_temp/temp_1966052730 -f /home/runner/work/_temp/7c187b07-8201-4bf2-b87d-247013d1c81d

gzip: stdin: not in gzip format
/bin/tar: Child returned status 1
/bin/tar: Error is not recoverable: exiting now
##[error]The process '/bin/tar' failed with exit code 2
##[error]Node run failed with exit code 1

After doing some googling, this looks to be the most relatable problem, but I notice it's not being downloaded the Oracle site, rather from this site so I don't think cookies are the issue. Has anyone else also encountered this error?

It would be useful for actions/setup-java and to use the same repository cache mechanism used by actions/cache to cache JDKs. This appears to be possible since the addition of https://github.com/actions/toolkit/tree/main/packages/cache in May.

setup-java should still look up the JDK to use (as the JDK determined by a semver spec and other options can change over time, e.g. as new updates get published). Once a specific JDK is determined (e.g. a specific tar.gz or .zip file URI is identified as a key), we can check (and populate) the cache to reuse the actual file hierarchy created for that JDK within that repository's cache across workflow runs. This can likely significantly improve workflow execution times, and bandwidth consumption.

It would be nice to add support for publishing to github pages.
According to this plugin documentation
https://github.github.com/maven-plugins/site-plugin/quickstart.html
It would mean expanding the settings.xml template in order to declare github as a server and it's credentials (I haven't seen support for token) and adding instructions on how to add the support in the pom.xml file

<server>
    <id>github</id>
    <username>YOUR_GITHUB_USERNAME</username>
    <password>YOUR_PASSWORD</password>
</server>

Currently, this action provides not just Java setup but Maven/Gradle as well. And this is not very convenient due to some reasons, for example, I may want to reconfigure Maven settings between steps, but for this, I need to call the whole setup-java action.

⚠️ Disclaimer: I'm only a beginner with GH actions 😉

I'm a little confused, I though according to https://github.com/actions/setup-java/blob/master/action.yml that there would be an output parameter path of the action, effectively pointing to the directory of the installed JDK. And in https://github.com/actions/setup-java/blob/master/src/installer.ts I would interprete core.setOutput('path', toolPath) to do exactly that 🤔

However I've created a little example here: https://github.com/codecholeric/simple-actions/blob/master/.github/workflows/example.yml

And in Print Output I don't see any outputs of the step 😕 Am I misunderstanding this?
https://github.com/codecholeric/simple-actions/runs/718201643?check_suite_focus=true

Also, why are there two sorts of naming conventions, the JAVA_HOME_version.with.dots_x64 and JAVA_HOME_versionWithoutDots_X64? The ENV variables with dots somehow cause problems for me, because e.g. Gradle System.env seems to just skip those environment variables as having an "illegal" identifier (in Bash I can also not export such a variable?).

👋 This issue is to track the move over to using main as the default branch for this repo. We’d love your team's help in completing this transition.

Do not remove your old default branch, customers are going to be using it. We will be sending messages out about these changes, but if you want to message in your repository, that's fine as well.

• Create a main branch.
• You might need to rebase any pull requests you want to merge before changing the default branch.
• Change the default branch in settings to main.
• Update any documentation in this repo to refer to the new branch name, although using the version tag is still preferred.
• Check that this Action works correctly for users who have a repository with a custom default branch name.
• Close this issue and celebrate 🎉

We are aiming to complete this work by July 17th July 24th.

Currently, as I understand it, the user may specify only one server, as follows:

- name: Setup Java.
  uses: actions/setup-java@v1
  with:
    java-version: 1.8
    server-id: value-of-server-id
    server-username: SERVER_USERNAME
    server-password: SERVER_PASSWORD

Which produces the following xml in the settings.xml file:

<server>
  <id>value-of-server-id</id>
  <username>value-of-server-username</username>
  <password>value-of-server-password</password>
</server>

However, it would be useful to be able to specify more than one server. For example, this yaml:

- name: Setup Java.
  uses: actions/setup-java@v1
  with:
    java-version: 1.8
    server-list:
      - server-id: value-of-server-id-1
        server-username: SERVER_USERNAME_1
        server-password: SERVER_PASSWORD_1
      - server-id: value-of-server-id-2
        server-username: SERVER_USERNAME_2
        server-password: SERVER_PASSWORD_2

Might produce the following xml in the settings.xml file:

<server>
  <id>value-of-server-id-1</id>
  <username>value-of-server-username-1</username>
  <password>value-of-server-password-1</password>
</server>
<server>
  <id>value-of-server-id-2</id>
  <username>value-of-server-username-2</username>
  <password>value-of-server-password-2</password>
</server>

While it would be valuable in general to be able to specify more than one server, it should be especially valuable in the context of Github, as it seems for now, in order to reference multiple packages from maven.pkg.github.com, the user must reference each package's repository in their pom.xml.

If the above configuration were possible, a user could then reference the artifacts at value-of-server-id-1 and value-of-server-id-2 in their pom.xml as follows:

<dependencies>
  <dependency>
    <groupId>group-id-for-owner</groupId>
    <artifactId>artifact-id-from-repository-1</artifactId>
    <version>version-1</version>
  </dependency>

  <dependency>
    <groupId>group-id-for-owner</groupId>
    <artifactId>artifact-id-from-repository-2</artifactId>
    <version>version-2</version>
  </dependency>
</dependencies>

<repositories>
  <repository>
    <id>value-of-server-id-1</id>
    <name>GitHub Packages</name>
    <url>https://maven.pkg.github.com/owner/artifact-id-from-repository-1</url>
  </repository>
  <repository>
    <id>value-of-server-id-2</id>
    <name>GitHub Packages</name>
    <url>https://maven.pkg.github.com/owner/artifact-id-from-repository-2</url>
  </repository>
</repositories>

Hi. Somewhy this action stopped working for me.

I get this output:

2019-11-22T20:29:03.8282479Z ##[section]Starting: Request a runner to run this job
2019-11-22T20:29:04.4018077Z Requesting a hosted runner in current repository's account/organization with labels: 'ubuntu-latest', require runner match: True
2019-11-22T20:29:04.4718879Z Labels matched hosted runners has been found, waiting for one of them get assigned for this job.
2019-11-22T20:29:04.5111217Z ##[section]Finishing: Request a runner to run this job
2019-11-22T20:29:12.7823163Z Current runner version: '2.160.2'
2019-11-22T20:29:12.7824338Z Prepare workflow directory
2019-11-22T20:29:12.8056056Z Prepare all required actions
2019-11-22T20:29:12.8084669Z Download action repository 'actions/checkout@v1'
2019-11-22T20:29:13.7985549Z Download action repository 'actions/setup-java@v1'
2019-11-22T20:29:14.6419126Z ##[error]/home/runner/work/_actions/actions/setup-java/v1/action.yml:
2019-11-22T20:29:14.6533927Z ##[error]/home/runner/work/_actions/actions/setup-java/v1/action.yml: (Line: 16, Col: 3, Idx: 552) - (Line: 16, Col: 3, Idx: 552): While parsing a block mapping, did not find expected key.
2019-11-22T20:29:14.6536021Z ##[error]Unexpected type '' encountered while reading 'action manifest root'. The type 'MappingToken' was expected.
2019-11-22T20:29:14.6557498Z ##[error]Fail to load /home/runner/work/_actions/actions/setup-java/v1/action.yml

My input:

name: Java CI

on: [push]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v1
      
    - name: Set up JDK 1.8
      uses: actions/setup-java@v1
      with:
        java-version: 1.8

I'm trying to install an x86 JDK in a GitHub action, and I found out that the specified architecture is ignored in this script. By looking at the code, I saw that arch is not used when the script is determining which archive to download. See

Be aware that Zulu doesn't seem to provide x86 Windows binaries for all Java versions.

With work being done towards adding additional binary distributions of OpenJDK as options (likely under the "distro" option, see e.g. #67), it would be useful to include the SapMachine binaries among the distro options

Hello,

I was advised to post my issue here from my GitHub Support Community post.

I've had a lot of weird issues at each stage of my pipeline and all of them seemed to have been resolved by setting the $PATH variable to /bin etc within the step or by hard coding /bin/chmod and /bin/ssh rather than using chmod and ssh for example.

I have tracked down the issue to the actions/setup-java@v1 step replacing the contents of $PATH with the path of the JDK.

I call it like this:

      - name: Set up JDK 13
        uses: actions/setup-java@v1
        with:
          java-version: 13

Before that step, echo $PATH outputs: /usr/share/rust/.cargo/bin:/home/runner/.config/composer/vendor/bin:/home/runner/.dotnet/tools:/snap/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/home/linuxbrew/.linuxbrew/bin:/home/linuxbrew/.linuxbrew/sbin

Whereas after that step, echo $PATH outputs:
/opt/hostedtoolcache/jdk/13.0.3/x64/bin:***

Hope this helps and let me know if you need anymore information!

The workflow file that reproduces this is here.

Thank you,
Kathan

I encountered a problem like the title.

name: Deploy the SNAPSHOT version to Maven Center

# Controls when the action will run. Triggers the workflow on push or pull request
# events but only for the master branch
on:
  push:
    branches: [ develop ]
  pull_request:
    branches: [ develop ]

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
      # Checkout source code
      - name: Checkout source code
        uses: actions/checkout@v2
      - name: Configure GPG Key
        run: |
          mkdir -p ~/.gnupg/
          printf "$MAVEN_GPG_PRIVATE_KEY" | base64 --decode > ~/.gnupg/private.key
          gpg --batch --import ~/.gnupg/private.key
        env:
          MAVEN_GPG_PRIVATE_KEY: ${{ secrets.MAVEN_GPG_PRIVATE_KEY }}
      # Install Java 1.8
      - name: Install Java
        uses: actions/setup-java@master
        with:
          java-version: 1.8
          server-id: hengyu
          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: Build with Maven
        run: mvn -B package --file pom.xml
      # Publish to Apache Maven Central
      - name: Publish to Apache Maven Central
        run: mvn deploy
        env:
          MAVEN_USERNAME: ${{ secrets.MAVEN_CENTER_USER_NAME }}
          MAVEN_CENTRAL_TOKEN: ${{ secrets.MAVEN_CENTER_PASSWORD }}
          #MAVEN_GPG_PASSPHRASE: ${{ secrets.MAVEN_GPG_PASSPHRASE }}

plugin config in pom.xml

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-gpg-plugin</artifactId>
    <version>${maven.gpg.plugin.version}</version>
    <executions>
        <execution>
            <id>sign-artifacts</id>
            <phase>verify</phase>
            <goals>
                <goal>sign</goal>
            </goals>
        </execution>
    </executions>
</plugin>

This action appears to install sbt on ubuntu-18.04, but not on macos-10.15.

Both Java 14 and 15 are already released, they are not ea any more.

When running:

    - name: Set up JDK 1.11
      uses: actions/setup-java@v1
      with:
        java-version: 1.11

On a self-hosted runner, the build fails saying:

1457fa28-9216-4663-b693-074afad52b42.sh: line 1: mvn: command not found

It works fine on github-hosted runners.

In order to use jpackage, one needs to download and extract the early access version of jdk 14. However, no installation is necessary. It would be nice if you could provide an option to download and extract java without installing it.

The download links for Java 14 can be found under: https://jdk.java.net/jpackage/

Certain projects might require multiple JDKs during build (e.g., Apache Log4j requires Java 7 and Java 9+ by means of toolchains.xml) and in its current form, that is not possible via setup-java.

When using self-hosted runners we provision compute with a Maven settings.xml and currently this action will overwrite our correct settings.xml with one that's inoperable. It would be nice to signal to the action to not generate a settings.xml file.

Another option might be to allow a template .github/workflow/maven/settings.xml that can be provisioned on the runner. In the case of running with GitHub actions proper the template can use ${{ secrets.references }} and in self-host just normal envars which Maven will interpolate into the settings file. Either way it's secure.

When calling the action several times, it will overwrite the JAVA_HOME environment variable and prepend it to the PATH, effectively shadowing a previous run of the action.
Fortunately, it will also set a JAVA_HOME_<version>_<architecture> environment variable, but this could be more idiomatic as an output parameter (in addition to the environment variable, which can also be useful on its own: #44 (comment))

This would be a great addition to #21

That way, one could write something like:

- name: Setup JDK 11
  id: setup-java-11
  uses: actions/setup-java@v1
  with:
    java-version: 11
    # here with #21, one would disable "installation"
- name: Setup JDK 14
  id: setup-java-14
  uses: actions/setup-java@v1
  with:
    java-version: 14
    # here with #21, one would disable "installation"
- name: Setup JDK 8
  # Ran last due each run shadowing the previous ones; see also #21
  uses: actions/setup-java@v1
  with:
    java-version: 8
- name: Build and run tests (with JDK 8)
  run: ./gradlew build
- name: Run tests with JDK 11
  run: ./gradlew test -Ptest.jdk-path="${{ steps.setup-java-11.outputs.jdk-path }}"
- name: Run tests with JDK 14
  run: ./gradlew test -Ptest.jdk-path="${{ steps.setup-java-14.outputs.jdk-path }}"

(here, the build is still running with JDK 8, but it coud configure its tests to actually use another JDK)

How does this action determine what version of gradle to use? Is it the latest version? Can we pin the version?

With java-version: "13":

Run actions/setup-java@v12s
##[error]Node run failed with exit code 1
Run actions/setup-java@v1
  with:
    java-version: 13
    architecture: x64
##[error]No valid download found for version 13.x. Check https://static.azul.com/zulu/bin/ for a list of valid versions or download your own jdk file and add the jdkFile argument
##[error]Node run failed with exit code 1

Looking at the https://static.azul.com/zulu/bin/ link, there is a jdk 13. I tried the full sematic version (13.0.0, 13.0.3) thinking perhaps that is what the action script expects. But that did not work as well.

The output from the action doesn't mention the version of JDK installed, which would be very useful to see.

Set up JDK
writing /home/runner/.m2/settings.xml
Run actions/setup-java@v1
/bin/tar --version
tar (GNU tar) 1.29
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by John Gilmore and Jay Fenlason.
/bin/tar xz --warning=no-unknown-keyword -C /home/runner/work/_temp/temp_540774269 -f /home/runner/work/_temp/a981e5ab-5d0c-4c33-99f2-53d62a23bdf4
creating settings.xml with server-id: github; environment variables: username=$GITHUB_ACTOR, password=$GITHUB_TOKEN, and gpg-passphrase=null
writing /home/runner/.m2/settings.xml

I am observing one issue with setup-java action. My project's gradle build is failing in junit test while running on github action, but same commit is passing in travis ci. It also passing in other linux environment.

• Github Project Commit - https://github.com/nitrite/nitrite-java/tree/ad3afc0641efc9d8425ac2ce59a037b00f5ccda9
• Travis CI Build - https://travis-ci.org/github/nitrite/nitrite-java/builds/717209688
• Github Action Build - https://github.com/nitrite/nitrite-java/runs/975425910?check_suite_focus=true

And here is the workflow file -

name: Gradle Build

on:
  push:
    branches:
      - 4.x

  pull_request:
    branches:
      - 4.x

jobs:
  build:
    runs-on: ubuntu-20.04
    steps:
      - uses: actions/checkout@v2
      - name: Set up JDK 1.8
        uses: actions/setup-java@v1
        with:
          java-version: 1.8.0.212
          java-package: jdk
          architecture: x64

      - name: Grant execute permission for gradlew
        run: chmod +x gradlew

      - name: Build with Gradle
        run: ./gradlew clean build

      - name: Prepare PGP Keys
        run: openssl aes-256-cbc -pass pass:$PGP_KEY_PASSWORD -in ./.ci/secring.gpg.enc -out ~/secring.gpg -d -md md5
        env:
          PGP_KEY_PASSWORD: ${{ secrets.PGP_KEY_PASSWORD }}

      - name: Publish packages to snapshot
        run: ./gradlew publish -Psigning.keyId=$PGP_KEY_ID -Psigning.password=$PGP_KEY_PASSWORD -Psigning.secretKeyRingFile=~/secring.gpg
        env:
          MAVEN_USERNAME: ${{ secrets.OSSRH_USER }}
          MAVEN_PASSWORD: ${{ secrets.OSSRH_PASSWORD }}
          PGP_KEY_ID: ${{ secrets.PGP_KEY_ID }}
          PGP_KEY_PASSWORD: ${{ secrets.PGP_KEY_PASSWORD }}
          GITHUB_TOKEN: ${{ secrets.NITRITE_GH_TOKEN }}

Any idea why it is failing specifically in github action only?

The current version specification logic in setup-java allows us to "spell" e.g. 14.0.0-ea, but semver version matching and comparison rules are "less than ideal". There are three key problems with the current logic:

1. It does not correctly match to the latest EA build: Semver will use build numbers (in the version forms of e.g. 14.0.0-ea+b28) in precedence comparisons. As a result, the current spelling will match to the first (not latest) ea build in the CDN

• Note: we've started hiding older EA build filenames from the index in the CDN to keep this working for people for now, but this is not a good practice or one we want to keep doing.

2. It does not allow the specification of a specific EA version (e.g. EA b27 vs EA b28). Semver will ignore build numbers (spelled with e.g. +b28), and match an explicitly requested e.g. 14.0.0-ea+b28 to a cdn 14.0.0-ea+b29
3. It does not support pre-release version formats that would allow #1 and #2 above to be resolved by changing the CDN file name to fit the existing logic. While the CDN can be populated with e.g. 14.0.0-ea.28, 14.0.0-ea will not match that. And will translated the current logic 14.0.0-ea.28 to 14.0.0-ea.28.x, which will not match (semver does not support .x syntax for pre-release version matching).

To prepare for an improvement, we have started populating the CDN with EA version number forms that semver can validly match and do comparisons on (e.g. 14.0.0-ea.28, 15.0.0-ea.2), but the current logic will not match to those. I will be issuing a pull request (shortly) with suggested logic updates that will correctly work with those new version number forms.= and solve the problems noted above.

It should be possible to set a specific Maven version to use with mvn. For that it should be optionally possible to download also Maven from some Apache mirror (https://maven.apache.org/download.cgi) after downloading Java and then use that mvn version.

Currently, using github actions I am downloading jdk using sdkman api and once downloaded a output is set which is sent to the next action, in this case is setup-java but I am getting no such file or directory, stat when the file is indeed present. You can find a build example here

Currently the filename is amazon-corretto-11.0.8.10.1-macosx-x64.tar.gz but if it is renamed to java-corretto.tar.gz then setup-java can find it.

Issue

When trying to use java version 9, 10, and 12 via a matrix the build fails. Error given is No valid download found for version <version>.x and package jre. Check https://static.azul.com/zulu/bin/ for a list of valid versions or download your own jdk file and add the jdkFile argument

I checked the link and there are no JRE versions for 9, 10, and 12 unless I missed them.

Steps to recreate

Create a workflow file with:

jobs:
  Test:
    runs-on: ${{ matrix.os }}
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-16.04, ubuntu-18.04, ubuntu-20.04, macos-latest, windows-2016, windows-2019]
        python-version: [2.7, 3.5, 3.6, 3.7, 3.8, pypy2, pypy3 ]
        java-version: [ 8, 9, 10, 11, 12, 13 ]
    steps:
    - uses: actions/checkout@v2

    - uses: actions/[email protected]
      with:
        java-version: ${{ matrix.java-version }}
        java-package: jre

Java version 8, 11, and 13 all completed their build fine. Is this expected because there are no versions inrepo, even though they are listed on the README or am I doing something wrong?

Link to failed run: https://github.com/Cyb3r-Jak3/html5validator/actions/runs/285144981
Job file: https://github.com/Cyb3r-Jak3/html5validator/blob/pypy3_support/.github/workflows/main.yml

I was setting up a Maven workflow. Everything worked fine locally and I was able to publish using mvn deploy -D token=TOKEN. When I added the actions/setup-java@v1 action, things mysteriously started to fail.

It turned out it would work as long as my repository wasn't called github. You can see the workflow fails when I rename the repository/server from foobarbaz to github:
https://github.com/actions-packages-examples/maven-example/commit/b529abbd86131a0da8feb1a3404be5d93d4a63f3

If I user needs to consume any packages, they will need to create a server configuration for every repository they're consuming packages from. Having a server called github implicitly defined is likely to get in the way and cause confusion.

Could we make it so that that server-id needs to be explicitly set and isn't automatically created?

With work being done towards adding additional binary distributions of OpenJDK as options (likely under the "distro" option, see e.g. #67), it would be useful to include the Oracle OpenJDK binaries among the distro options

Hello Team,

Im trying to setup a workflow with java 1.6 and maven 3.2.5 (stCarolas/setup-maven@v3). Im getting "Exception in thread "main" java.lang.UnsupportedClassVersionError: org/codehaus/plexus/classworlds/launcher/Launcher : Unsupported major.minor version 51.0" error in Ubuntu-latest runner.

I see your readme file says it has support for version 6. Let me know any workaround here.

Thanks,
Bharani.

With work being done towards adding additional binary distributions of OpenJDK as options (likely under the "distro" option, see e.g. #67), it would be useful to include Amazon Corretto among the distro options.

I've two actions, one for CI, one for publishing, both configured to install JDK 8. On one occasion, compilation passed on the former, but failed on the latter.

Passed:
https://github.com/asarkar/coroutines-test/runs/985108815?check_suite_focus=true

Failed:
https://github.com/asarkar/coroutines-test/runs/985085884?check_suite_focus=true

Given that the JDKs are not installed into the hosted toolcache, the current code searching for a JDK on a GitHub hosted runner will always be a "cache miss" the first time:

At the recommendation of one of the virtual-environments maintainers, I'm raising the issue here.

With work being done towards adding additional binary distributions of OpenJDK as options (likely under the "distro" option, see e.g. #67), it would be useful to include the dragonwell binaries among the distro options

We should be using the release strategy specified by https://github.com/actions/toolkit/blob/master/docs/action-versioning.md#recommendations

To get there, we need to:

1. Create a releases/v1 branch and move the v1 tag and future releases there
2. Warn that we will deprecate the master branch and that you should attach to v1 instead. We will support master in a warned but deprecated state for ~1 month.
3. Switch the warning to an error on master. Remove node_modules from the master branch. We will stay in this state for ~1 month.
4. Remove the error on master.

During steps 2 and 3, we need to be extra careful to not check the warning/error into the releases branch.

Since a bit more than an hour, suddenly this action became extremely slow - it takes 5-10 minutes to run.

We have multiple workflows which look like this:

jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 6    steps:
      - uses: actions/checkout@v2
      - name: Setup Java
        uses: actions/setup-java@v1
        with:
          java-version: "11"
          architecture: "x64"

Which now time out because the "Setup Java" step takes too long, and is aborted:

Run actions/setup-java@v1
  with:
    java-version: 11
    architecture: x64
    java-package: jdk
    server-id: github
    server-username: GITHUB_ACTOR
    server-password: GITHUB_TOKEN
Error: The operation was canceled.

With debugging enabled, I get this output:

Run actions/setup-java@v1
##[debug]isExplicit: 
##[debug]explicit? false
##[debug]evaluating 0 versions
##[debug]match not found
##[debug]Downloading JDK from Azul
##[debug]Searching for files with extension: -linux_x64.tar.gz
##[debug]Downloading https://static.azul.com/zulu/bin/zulu11.41.23-ca-jdk11.0.8-linux_x64.tar.gz
##[debug]Downloading /home/runner/work/_temp/396c3e9f-c908-4376-bc75-60add47a4e50
##[debug]Re-evaluate condition on job cancellation for step: 'Setup Java'.

Hello,
the Maven examples in the README could probably be improved:

1. Improve command line parameters, see also actions/starter-workflows#538
2. Remove redundant step name: Build with Maven, deploy already includes package so it essentially runs package (and all phases before it) twice
   Edit: deploy would skip compiling (since package already did this), but would run tests again.
3. Add --batch-mode to deploy to prevent output which is intended for interactive console
4. Write out -s as --settings to make it easier to understand for users who are not familiar with all command line options
5. Change name "Publish to GitHub Packages Apache Maven" to "Publish to GitHub Packages with Maven" to be consistent with other message or drop "with Maven" to be consistent with Gradle step names
6. It might be possible to run deploy with -Dmaven.install.skip=true to skip installing the package to the local repository since that could cause issues when a cache step is used and a large number of the packages of the project accumulate (only happens if the version of the package changes frequently). Though would be good if someone with more Maven deployment experience could confirm this.

Note that GitHub Help: Publishing Java packages with Maven would have to be updated accordingly.

Let me know if you want me to write a pull request.

See also actions/starter-workflows#539

Associated community ticket: https://github.community/t/use-gpg-private-key-within-github-actions-and-setup-java-sdk/127133

The customer is trying to publish his Java package to the Maven Central Repository and GitHub Packages in a GitHub Actions workflow. He is authenticating with the GPG key to publish the package.
He refers to the examples mentioned in "Publishing Java packages with Maven" and the README of the setup-java action to setup the workflow.
But he gets the following errors:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-gpg-plugin:1.6:sign (sign-artifacts) on project ***: Unable to decrypt gpg passphrase: org.sonatype.plexus.components.sec.dispatcher.SecDispatcherException: java.io.FileNotFoundException: /home/runner/.m2/settings-security.xml (No such file or directory) -> [Help 1]

OR

gpg: signing failed: Inappropriate ioctl for device

Something like

- uses: actions/setup-java@v1
  with:
    java-version: '1.8'
    javafx: true

I believe Zulu just has ca-fx in the name of jdk versions with JavaFX.

With work being done towards adding additional binary distributions of OpenJDK as options (likely under the "distro" option, see e.g. #67), it would be useful to include the Liberica binaries among the distro options