GitHub Community
Public composite action: should we call actions/checkout and actions/setup-java?
#73309
Select Topic AreaQuestion BodyWe 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 What if the calling workflow does include the
|
Replies: 4 comments 3 replies
|
You should design your action to work with a broader range of Java versions, thereby reducing the potential for conflicts. |
|
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. |
|
Related issue: actions/setup-java#552 which might solve the As a workaround, I guess we could hack...save all the env | grep '^JAVA_HOME_|^PATH' > "${{ runner.temp }}/pre-vars"and then as 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? |
|
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:
|
|
Another - name: "Execute my Java-requiring thing"
env:
PATH: "${{ env.JAVA_HOME_17_X64 }}/bin:${{ env.PATH }}"
shell: bash
run: java -jar foo.jarSadly, this does not work however awesome it looks at first sight. In composite actions However, this works: - name: "Execute my Java-requiring thing"
shell: bash
run: |
PATH="${JAVA_HOME_17_X64}/bin:${PATH}"
java -jar foo.jarNote: the author of the composite action is responsible for correct architecture selection! |
|
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. |
|
@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:
This was the driver to file PR setup-java#553 Feel free to fork or make use of |
Related issue: actions/setup-java#552 which might solve the
actions/setup-javapart.As a workaround, I guess we could hack...
save all the
JAVA_HOME*andPATHvariables to a temp file, something like:and then as a
post:/last step (if: success() || failure()): do a(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?