Support shell environment variables in more fields

[aep-sunlife]

Description:

Fields like java-version aren't processing shell environment variables. Consequently, establishing a primary source of truth for version numbers involves quite elaborate boilerplate, especially when reusing version numbers across multiple workflows.

Task version:

4

Platform:

Tested on Ubuntu, likely happens on the others as well.

Runner type:

• Hosted
• Self-hosted

Repro steps:

    - run: ". .github/workflows/tools.sh"
    - uses: "actions/setup-java@v4"
      with:
        distribution: "corretto"
        java-version: "$JAVA_VERSION"

Expected behavior:

java-version populates with a value of 17, based on a JAVA_VERSION='17' command in a reusable tools.sh script.

Actual behavior:

setup-java treats $JAVA_VERSION as a string literal.

Workaround

tools.txt:

JAVA_VERSION=17
SHELLCHECK_VERSION=0.10.0
STANK_VERSION=0.0.31
...

build.yaml:

---
name: "Build"
on: # yamllint disable-line rule:truthy
  push:
  pull_request:
  schedule:
  # Each day at midnight
  - cron: "0 0 * * *"
  workflow_dispatch:
jobs:
  Build:
    runs-on: "ubuntu-24.04"
    steps:
    - uses: "actions/checkout@v4"
    - run: "cat .github/workflows/tools.txt >> \"$GITHUB_OUTPUT\""
      id: "tools"
    - uses: "actions/setup-java@v4"
      with:
        distribution: "corretto"
        java-version: "${{ steps.tools.outputs.JAVA_VERSION }}"
    - run: "gradle build"

A rube goldberg involving expressions and outputs can succeed, but it results in code that's harder to read and write.

Ideally, the field updates to account for shell variables.

This needs to be done in a platform agnostic way. We can reasonably support at least POSIX shell syntax, Command Prompt, and PowerShell. We may constrain the POSIX variable expansion syntax to at most $VAR and ${VAR}, with no default values or substitutions, for simplicity.

[mahabaleshwars]

Hi @aep-sunlife,
Thank you for creating this issue. We will investigate it and provide feedback as soon as we have some updates.

[mahabaleshwars]

Hi @aep-sunlife,

To ensure that the JAVA_VERSION environment variable is properly set and used across different steps in the workflow, you need to:

1. Source the tools.sh script in the workflow to set the JAVA_VERSION variable in the shell running the actions.
2. Export the JAVA_VERSION variable to $GITHUB_ENV. Since each step in GitHub Actions runs in a separate shell, environment variables need to be explicitly exported using $GITHUB_ENV to persist across steps within the same job.

By appending to $GITHUB_ENV, the JAVA_VERSION variable becomes available throughout the entire job. Without this step, the variable would only be accessible within the scope of the first run block (the script sourcing), and subsequent steps wouldn't have access to it.

Here’s how you can modify your workflow:

- name: Set up Java version
  run: |
    # Source tools.sh to set the JAVA_VERSION environment variable
    source .github/workflows/tools.sh

    # Export JAVA_VERSION to $GITHUB_ENV to persist it across subsequent steps
    echo ""JAVA_VERSION=$JAVA_VERSION"" >> $GITHUB_ENV

- name: Set up Java using the exported JAVA_VERSION
  uses: ""actions/setup-java@v4""
  with:
    distribution: ""corretto""
    java-version: ""${{ env.JAVA_VERSION }}""  # Use the JAVA_VERSION from $GITHUB_ENV