Replies: 1 comment
-
🕒 Discussion Activity Reminder 🕒 This Discussion has been labeled as dormant by an automated system for having no activity in the last 60 days. Please consider one the following actions: 1️⃣ Close as Out of Date: If the topic is no longer relevant, close the Discussion as 2️⃣ Provide More Information: Share additional details or context — or let the community know if you've found a solution on your own. 3️⃣ Mark a Reply as Answer: If your question has been answered by a reply, mark the most helpful reply as the solution. Note: This dormant notification will only apply to Discussions with the Thank you for helping bring this Discussion to a resolution! 💬 |
Beta Was this translation helpful? Give feedback.
-
Select Topic Area
Question
Body
I have a composite action that invokes a tool that requires Java 17, but potentially the invoking workflow may be using a different Java version. As such, I'd like my composite action to do something like this:
JAVA_HOME
andPATH
actions/setup-java
JAVA_HOME
in aTOOL_JAVA_HOME
environment variable, to be used later to invoke the toolJAVA_HOME
andPATH
from step 1Restoring
JAVA_HOME
is easy, but my attempts to restorePATH
have failed so far;echo "PATH=${ORG_PATH}" >> $GITHUB_ENV
doesn't seem to update thePATH
, andecho "${ORG_PATH}" >> $GITHUB_PATH
duplicates the path entries.Some alternative approaches that came to mind:
actions/setup-java
should allow for setting up a given Java version/distribution but without setting any environment variables; subsequent steps could access Java path through${{ steps.setup_java_step.outputs.path }}
. Is there any way to preventsetup-java
from setting any environment variables?JAVA_HOME_17_X64
, which is available by default on GitHub-hosted runners, however this may not be available on self-hosted runners and potentially I'd need to check the runner architecture to select the correct environment variable name (for now we only support X64, but eventually we want to support arm64 as well)echo "${ORG_JAVA_HOME}/bin" >> $GITHUB_PATH
to have the original Java version first on thePATH
againAny better approaches for accomplishing this? Unless we can somehow accomplish approach
1
, I guess approach3
is the best work-around? Note that we need to support Linux, Windows & Mac runners, both GitHub-hosted & self-hosted.Beta Was this translation helpful? Give feedback.
All reactions