"experimental_platform_in_output_dir" caused action conflict on M1

[sluongng]

Description of the bug:

A detailed description could be found here bazel-contrib/rules_go#3851

Which category does this issue belong to?

Configurability

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

Make sure to use an ARM64 MacOS machine to reproduce this.

gh repo clone buildbuddy-io/buildbuddy
cd buildbuddy
git checkout c454fd9dd
bazel clean --async && bazel build //enterprise/server/cmd/executor:executor

Which operating system are you running Bazel on?

MacOS

What is the output of bazel info release?

release 7.0.2

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

No response

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

No

Have you found anything relevant by searching the web?

No response

Any other information, logs, or outputs that you want to share?

See the discussion in bazel-contrib/rules_go#3851

[katre]

One workaround, if you want to keep --experimental_platform_in_output_dir, is to also use --experimental_override_name_platform_in_output_dir, which lets you update the platform->name mapping.

I'm not sure if there's a good way to detect this during the action conflict check and suggest it, but it would be nice if we could.

[gregestren]

I think I see the problem.

As bazel-contrib/rules_go#3851 (comment) mentions, --experimental_platform_in_output_dir defaults the path to the platform's base label name (like :foo). Which can easily clash.

But if you set --experimental_use_platforms_in_output_dir_legacy_heuristic to false, the default becomes a hash of the platform's full label. That should be crash-proof.

I think we should default --experimental_use_platforms_in_output_dir_legacy_heuristic to false. This is already disabled in Google, where we're ready to enable --experimental_platform_in_output_dir by default.

I have to admit the resulting paths are much cleaner when you can set --experimental_override_name_platform_in_output_dir mappings (see bazel-contrib/rules_go#3851 (comment)). We don't yet have better logic that allows setting this from distributed sources.

[gregestren]

I wrote a doc a while ago explaining the interplay between all these flags and how they affect what output paths look like. Happy to share if anyone wants a summarized reference.

@katre , @aranguyen and I are also trying to clean up and remove these flags as much as we can. Some of them are pure legacy logic that AFAIU is no longer relevant.

[sluongng]

cc: @fmeum

I think turning off experimental_use_platforms_in_output_dir_legacy_heuristic will make all the bazel-out paths take the form of platform_<hash> right?

If that's the case, I would prefer if this is an opt-in flag as the current approach is still much friendlier to end-users.
Perhaps, we could document the flags better as a solution to action conflict between platforms.
Something like:

When multiple platforms are involved in a build process, they may share the same path in bazel-out, leading to potential conflicts where different actions target the same output file path. This can result in action conflict errors. To prevent these errors, users can disable the platform path calculation heuristic by setting --use_platforms_in_output_dir_legacy_heuristic=false. This adjustment ensures that each platform uses a unique hash-based path within bazel-out, thus avoiding conflicts. Alternatively, the --override_name_platform_in_output_dir flag allows users to customize the output path names for each platform, enhancing their manageability.

[gregestren]

I wrote a doc a while ago explaining the interplay between all these flags and how they affect what output paths look like. Happy to share if anyone wants a summarized reference.

See Platforms in output paths review - an attempt to cleanly explain what all the flags do and their history.

I think turning off experimental_use_platforms_in_output_dir_legacy_heuristic will make all the bazel-out paths take the form of platform_ right?

Exactly.

As mentioned in the doc I'd love to be able to globally default --experimental_platform_in_output_dir. But I'm not sure what the right balance is for clean paths vs. action conflict safety.

One option is use platform base names and have Bazel actively check for clashes and cleanly error builds that mix platforms in unsafe ways. Then it's up to users to organize to avoid that.