It seems like the current repository rules are setting up graalvm toolchain based on rctx.os, which works for local execution.
However, if you try to do a cross-platform build using remote execution, i.e. using a MacOS ARM64 laptop to remote build on a Linux AMD64 RBE setup, then the repository rule would prepare the wrong binary (i.e. download the MacOS binary to upload + execute on Linux RBE worker).
A better approach would be similar to rules_go: declare a matrix of common CPU/Arch and register all of the toolchains available matching that matrix. Toolchains are lazily loaded, so registering them will not cause them to be downloaded. They will be downloaded automatically by Bazel according to the build dependency graph.
It seems like the current repository rules are setting up graalvm toolchain based on
rctx.os, which works for local execution.However, if you try to do a cross-platform build using remote execution, i.e. using a MacOS ARM64 laptop to remote build on a Linux AMD64 RBE setup, then the repository rule would prepare the wrong binary (i.e. download the MacOS binary to upload + execute on Linux RBE worker).
A better approach would be similar to rules_go: declare a matrix of common CPU/Arch and register all of the toolchains available matching that matrix. Toolchains are lazily loaded, so registering them will not cause them to be downloaded. They will be downloaded automatically by Bazel according to the build dependency graph.