Description:
The accepted values for java-package are not defined or validated consistently across the action contract, distributor implementations, documentation, and end-to-end tests.
Some distributor implementations interpret unknown package values as their default JDK package or fail only after remote version resolution. For example, the JetBrains installer’s default switch branch maps any unrecognized value to jbrsdk. This can hide workflow typos and install a different package than requested.
The published contract is also incomplete: JetBrains variants such as jdk+jcef, jre+jcef, jdk+ft, and jre+ft are implemented and exercised by E2E tests but are absent from action.yml and the README.
Introduce explicit package capability validation before any cache lookup or network request. Each distribution should declare or validate its supported package types, including version-specific constraints such as Temurin jdk+jmods. Unknown or unsupported combinations must fail with a message that includes the distribution, requested package type, and supported values.
Add reusable contract tests that keep distributor behavior, action.yml, README documentation, and E2E package matrices aligned.
Task version:
v6
Platform:
Runner type:
Repro steps:
Configure a package type that is not supported by the selected distribution, or contains a typo. For example:
- uses: actions/setup-java@v6
with:
distribution: jetbrains
java-version: '21'
java-package: jdk+jceffAlso compare the JetBrains package variants exercised in .github/workflows/e2e-versions.yml with the values documented in action.yml and README.
Expected behavior:
The action validates java-package before installation. Unsupported values fail immediately with a descriptive list of valid package types for the selected distribution. All supported variants are documented consistently and protected by contract tests.
Actual behavior:
Unsupported values may silently select the default JDK package or fail later during remote resolution. Several supported JetBrains variants are exercised by E2E tests but omitted from the published input contract.
Description:
The accepted values for
java-packageare not defined or validated consistently across the action contract, distributor implementations, documentation, and end-to-end tests.Some distributor implementations interpret unknown package values as their default JDK package or fail only after remote version resolution. For example, the JetBrains installer’s default switch branch maps any unrecognized value to
jbrsdk. This can hide workflow typos and install a different package than requested.The published contract is also incomplete: JetBrains variants such as
jdk+jcef,jre+jcef,jdk+ft, andjre+ftare implemented and exercised by E2E tests but are absent fromaction.ymland the README.Introduce explicit package capability validation before any cache lookup or network request. Each distribution should declare or validate its supported package types, including version-specific constraints such as Temurin
jdk+jmods. Unknown or unsupported combinations must fail with a message that includes the distribution, requested package type, and supported values.Add reusable contract tests that keep distributor behavior,
action.yml, README documentation, and E2E package matrices aligned.Task version:
v6
Platform:
Runner type:
Repro steps:
Configure a package type that is not supported by the selected distribution, or contains a typo. For example:
Also compare the JetBrains package variants exercised in
.github/workflows/e2e-versions.ymlwith the values documented inaction.ymland README.Expected behavior:
The action validates
java-packagebefore installation. Unsupported values fail immediately with a descriptive list of valid package types for the selected distribution. All supported variants are documented consistently and protected by contract tests.Actual behavior:
Unsupported values may silently select the default JDK package or fail later during remote resolution. Several supported JetBrains variants are exercised by E2E tests but omitted from the published input contract.