Public composite action: should we call actions/checkout and actions/setup-java?

[rsenden]

Select Topic Area

Question

Body

We developed some public GitHub Actions that allow users to scan their source code. Some of the steps in our composite actions require Java to be available (even if the source code to be scanned is not Java), and obviously we require the source code to be checked out.

Does it make sense to call actions/checkout and actions/setup-java from our composite actions, thereby simplifying action usage as workflows then no longer need to explicitly declare these steps to their workflow, while allowing us to make sure that the correct Java version as required by our software has been installed?

What if the calling workflow does include the checkout or setup-java steps, potentially installing a Java version that's incompatible with our software?

• Can we somehow detect this (I guess for setup-java we could check the JAVA_HOME_{{ MAJOR_VERSION }}_{{ ARCHITECTURE }} environment variables)?
• Can we call setup-java without making the selected Java version the default version (i.e., without adding it to the PATH), such that we don't 'override' the Java version installed by the calling workflow?

[jge162]

You should design your action to work with a broader range of Java versions, thereby reducing the potential for conflicts.

[rsenden]

Thanks, good suggestion, but unfortunately the action needs to invoke some Java applications that are not compatible with all Java versions. For example, some of the Java applications are not compatible with Java 8, which according to GitHub docs is the default on GitHub-hosted Windows runners, and also some users may require Java 8 for building their applications.

So, we either need to instruct users to run the appropriate setup-java step before invoking our action, or (preferred) have our action set up the appropriate Java version without affecting any Java setup done by the calling workflow.

[TWiStErRob]

Related issue: actions/setup-java#552 which might solve the actions/setup-java part.

As a workaround, I guess we could hack...

save all the JAVA_HOME* and PATH variables to a temp file, something like:

env | grep '^JAVA_HOME_|^PATH' > "${{ runner.temp }}/pre-vars"

and then as a post:/last step (if: success() || failure()): do a

cat ${{ runner.temp }}/pre-vars" >> "${GITHUB_ENV}"

(totally untested, scripts only for comms.)

Re checkout: I would leave that to the user, because you can't know how to clone their repo (submodules, sparse, history, token!, etc.).

Considering the age of this, what did you end up doing?

[rsenden]

Many thanks for the suggestion, looks like a viable work-around. Until now, we simply leave it to the calling workflow to set up a supported Java version.

Our situation is a bit special; The Java software that we're running (which requires a specific Java version) in our composite action actually runs the user-supplied Maven/Gradle build (which may require a different Java version). So, this means that we may need to have two different Java versions installed.

I guess we could still use this hack by doing something like the following:

• env | grep '^JAVA_HOME_|^PATH' > "${{ runner.temp }}/pre-vars"
• Run setup-java to install the Java version required by our software
• echo TOOL_JAVA_HOME=$JAVA-HOME >> "${GITHUB_ENV}"
• cat ${{ runner.temp }}/pre-vars" >> "${GITHUB_ENV}"
• Invoke our tool using TOOL_JAVA_HOME, which invokes Maven/Gradle with the original, user-supplied JAVA_HOME

[TWiStErRob]

Another actions/setup-java workaround if you don't need a very special Java (i.e. it's pre-installed):

    - name: "Execute my Java-requiring thing"
      env:
        PATH: "${{ env.JAVA_HOME_17_X64 }}/bin:${{ env.PATH }}"
      shell: bash
      run: java -jar foo.jar

Sadly, this does not work however awesome it looks at first sight. In composite actions ${{ env. is just empty.

However, this works:

    - name: "Execute my Java-requiring thing"
      shell: bash
      run: |
        PATH="${JAVA_HOME_17_X64}/bin:${PATH}"
        java -jar foo.jar

Note: the author of the composite action is responsible for correct architecture selection!

[rsenden]

Might be easier than the above for our specific use case, however I don't think we can assume that the required Java version is pre-installed; this might be the case for GitHub-hosted runners but probably not for self-hosted runners.

[mhoffrog]

@TWiStErRob Maybe it could be of help looking up to the way I did use it at https://github.com/mavenplugins/reusable-gh-actions/blob/master/.github/workflows/__maven_clean_deploy.yml

This is:

• setting up to two different JAVA versions - regardless of the one the GitHub runners Docker image is providing
• deriving the JAVA version required from the projects Maven pom and setting up an additional JAVA version for the Maven toolchain to be used if this is required.
• separate the JAVA runtime required to run Maven from the one required to compile the project artifacts. Both JAVA runtimes are installed at a time.

This was the driver to file PR setup-java#553

Feel free to fork or make use of uses: GHCICD/setup-java@vHEAD-GHCICD-552 to give it a try, if you like.