Support for dynamic `mill-jvm-version` in front matter

[gavares]

Mill Version: 1.0.0-RC-68-43069c

Use Case

Our team uses mill front matter to specify mill-jvm-id pointing to an internal corporate Artifactory URL for JVM download. We really like using feature because it means that any developer who does a git clone doesn't need to install anything else to start working with and building the codebase.

The front matter in our build.mill file currently looks like:

//| mill-version: 1.0.0-RC2-68-43069c-native
//| mill-jvm-version: https://artifactory.mycompany.com/graalvm-bundle/graalvm/release/24.2.1/gftc/graalvm-jdk-24.0.1_macos-aarch64_bin.tar.gz

The URL above specifies a GraalVM version that works specifically for MacOs and Arm64.

Our build system is composed only of AMD64 Linux hosts and the URL specified in the front matter fails in that scenario.

Request

Allow for some level of dynamic configuration or overrides for the values defined in front matter.

Proposals

1. When JAVA_HOME environment variable is set, mill chooses that value for the mill-jvm-id and falls back to front matter if that variable isn't defined.
2. Mill CLI supports a flag that can be used to forcefully override the mill-jvm-id and, when specified, ignores the value in front matter
3. Mill has the ability to interpolate environment variables into all values in front matter like it does with $MILL_VERSION in the mvnDeps array. With this, we could simply export OS and ARCH env variables and our URL takes the form: ..../graalvm-jdk-24.0.1_${OS}-${ARCH}_bin.tar.gz