vlsi opened a new pull request, #6716:
URL: https://github.com/apache/jmeter/pull/6716
### Why
`matrix.js` builds the CI test matrix, and each row's `java_vendor` is meant
to pin the JDK vendor for the test toolchain (`jdkTestVendor` → Gradle). The
per-row post-processing read it from `v.java_distribution.vendor` *after*
`v.java_distribution` had been reassigned to its string `value`. Reading
`.vendor` off a string yields `undefined`, so `jdkTestVendor` reached Gradle
empty and the test toolchain was never pinned to the matrix vendor — tests
could run on any installed JDK of the matching version, which defeats varying
the distribution across rows.
### What
Destructure the axis object before overwriting the field, so the read no
longer depends on statement order:
```js
const {value: javaDistribution, vendor: javaVendor} = v.java_distribution;
v.java_distribution = javaDistribution;
v.java_vendor = javaVendor;
```
### How to verify
`npm ci --prefix .github/workflows && MATRIX_JOBS=8 node
.github/workflows/matrix.js` — every row now carries a real `java_vendor`
(`amazon`, `bellsoft`, `microsoft`, `oracle`, `eclipse`, `azul`) instead of
`undefined`.
This makes the test toolchain actually request the matrix vendor. With
`org.gradle.java.installations.auto-download=false`, the workflow already
provisions a matching-vendor JDK for the test version via `actions/setup-java`
(`distribution: ${{ matrix.java_distribution }}`), so the constraint is
satisfiable.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
