Parameterize tool downloads by execution platform

[trevorc]

Previously, the existing toolchain configuration directed all target platforms to a single artifact repository (e.g., @helm_tool//:tool). This base repository used host platform detection to download a single binary. Consequently, cross-compilation and remote execution failed when the execution platform architecture differed from that of the host.

This commit enables cross-compilation by isolating artifacts into platform-specific repositories:

• The download_tool macro iterates over _TOOLS_BY_RELEASE to instantiate independent repositories for each OS and architecture combination (e.g., @helm_tool_linux_arm64).
• The base repository fallback is removed to prevent host-architecture leakage in remote execution environments.
• The native.toolchain declarations point to @{tool_repo}_{os}_{arch}//:tool, directing Bazel to fetch the artifact repository matching the requested execution platform.
• An analysistest suite in toolchain_test.bzl verifies that linux_amd64 and linux_arm64 constraints resolve to their respective architectural repositories.

[trevorc]

Friendly ping!

[seh]

I haven't studied your proposed implementation yet; instead, I've been considering the problem that you posed. There's no motivating issue filed to complain about it, so that leaves us to discuss the problem and potential solutions within the context of a single proposed solution.

I generally don't merge patches, at least not until I've thought through how I'd solve the problem. You have raised a problem that I had not needed to consider in my own use of this rule set, at least thus far. That doesn't mean it's not a real problem. That just means that I haven't thought about how to solve this problem.

[trevorc]

Thanks for the response. Understandable; I have filed an issue to this effect: #8

The problem arises in remote execution environments where the machine initiating the build (the Bazel client) has a different CPU architecture than the remote workers executing the actions. For example, a developer on an AMD64 workstation dispatching builds to ARM64 remote executors.

Currently, when the repository rules fetch the kustomize and helm tools, they detect the OS and architecture of the host machine running the Bazel client. They download the single binary that matches the host and provide it to the toolchain.

When Bazel later dispatches a kustomize action to a remote worker, it sends that host-platform binary. If the remote worker has a different architecture, for instance, it cannot run the binary and fails with an Exec format error. To support this kind of cross-platform remote execution, the ruleset needs a way to provide a binary that matches the execution platform rather than the host platform.

The approach I explored in the patch was to have the repository rule fetch the pre-compiled binaries for the various supported platforms upfront. By declaring a distinct toolchain for each (using exec_compatible_with), Bazel's toolchain resolution can select the appropriate binary based on the target execution platform at analysis time. This is modeled after rules_go, jq.bzl, rules_python, rules_rust etc. which take an analogous approach.