fix: make OCI helper actions explicit about toolchains#900
fix: make OCI helper actions explicit about toolchains#900keegancsmith wants to merge 2 commits into
Conversation
The --incompatible_auto_exec_groups flag requires Starlark actions to declare whether their executable/tools come from an action toolchain. This is not a Bazel default today, but it is exposed through strict preset configurations and is intended to catch rules that rely on implicit action toolchain inference. The descriptor and load helpers combine tools from several toolchains. Mark those helper actions with toolchain = None, matching the main OCI image action, so their action toolchain behavior is explicit without changing their inputs or execution model.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 35f99d5da2
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| ], | ||
| mnemonic = "OCIDescriptor", | ||
| progress_message = "OCI Descriptor %{input}", | ||
| toolchain = None, |
There was a problem hiding this comment.
When --incompatible_auto_exec_groups is enabled, this action still invokes tools from multiple toolchains (jq, zstd, coreutils, and regctl via tools/HPATH) but declares toolchain = None. Bazel's AEG guide says None is only for actions that do not use a toolchain, and multi-toolchain actions need a custom exec_group; otherwise the descriptor action can be analyzed while running toolchain-selected binaries on an exec platform that does not match them in mixed remote-execution setups.
Useful? React with 👍 / 👎.
| coreutils.coreutils_info.bin, | ||
| ], | ||
| mnemonic = "OCITarballManifest", | ||
| toolchain = None, |
There was a problem hiding this comment.
This load helper action uses toolchain-provided executables (jq/coreutils here, and the tar action below uses bsdtar) but opts out with toolchain = None. Under automatic exec groups, Bazel only guarantees the correct execution platform when the action names the relevant toolchain or a custom exec group containing all toolchains; with this setting, cross-platform or remote builds can run the generated load/tar scripts on a default exec platform that doesn't match the selected tool binaries.
Useful? React with 👍 / 👎.
The first cut made the affected actions explicit for --incompatible_auto_exec_groups, but using toolchain = None still leaves toolchain-provided binaries resolved separately from the action execution platform. Use custom exec groups for the OCI actions that invoke tools from several toolchains, and read those toolchain providers from the same exec groups that run the actions. The tarball action uses one tar toolchain executable, so name that action toolchain directly. Test Plan: USE_BAZEL_VERSION=7.6.2 bazel build --incompatible_auto_exec_groups //examples/assertion:case2 //examples/assertion:case5_tar //examples/image_index:app_all //examples/image_index:app_all_annotated //oci/private:image //oci/private:load //oci/private:image_index bazel build --incompatible_auto_exec_groups //examples/assertion:case2 //examples/assertion:case5_tar //examples/image_index:app_all //examples/image_index:app_all_annotated //oci/private:image //oci/private:load //oci/private:image_index bazel build //examples/assertion:case2 //examples/assertion:case5_tar //examples/image_index:app_all //examples/image_index:app_all_annotated //oci/private:image //oci/private:load //oci/private:image_index
1 participant
The --incompatible_auto_exec_groups flag requires Starlark actions to declare whether their executable/tools come from an action toolchain. This is not a Bazel default today, but it is exposed through strict preset configurations and is intended to catch rules that rely on implicit action toolchain inference.
The descriptor and load helpers combine tools from several toolchains. Mark those helper actions with toolchain = None, matching the main OCI image action, so their action toolchain behavior is explicit without changing their inputs or execution model.