remove need for --define=EXECUTOR=remote in remote execution

[buchgr]

This is mainly used by Bazel to force compiling singlejar and ijar from source when running actions on a remote execution system that might not be compatible with the precompiled singlejar and ijar versions.

Make this obsolete by defining the right platform constraints.

[ittaiz]

+1

…

On Fri, 25 Jan 2019 at 16:56 Jakob Buchgraber ***@***.***> wrote: This is mainly used by Bazel to force compiling singlejar and ijar from source when running actions on a remote execution system that might not be compatible with the precompiled singlejar and ijar versions. Make this obsolete by defining the right platform constraints. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#7254>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIF79o0BwltJFsjjlVfeCdr-RhWhbMks5vGxs1gaJpZM4aTB4J> .

[katre]

Taking a look to see how we can use a config_setting to help with this.

[buchgr]

@katre what's the status of this?

[katre]

@agoulti tested a few variations, and ended up stuck on the fact that what is needed is a config_setting that can detect host vs remote, even when host and remote are identical. No good solution to this yet.

[agoulti]

I'd say the problem is the combination of these two factors:

• Currently the platform definition does not capture enough information to know if the pre-built binary will work on that platform
• We can't reliably tell if we're on the host platform. Since Bazel doesn't transition platforms properly yet, a common workaround is to set the local platform to be remote, so even if we had a way of checking if the chosen platform is the same as local, we can't rely on this in the current state of the world.

[vincyyou]

.

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 2.5 years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[uri-canva]

Is this related to Execution Platforms vs. Strategies?

[katre]

The define would probably be able to be removed if these were unified, yes.

[uri-canva]

Do you know if there's any work being done on that? It's shown as approved currently: https://github.com/bazelbuild/proposals/blob/afa38929278b7c20870125d1d32394955967263f/README.md?plain=1#L72 but the last update is a while ago and I haven't stumbled on things related to it in the code.

[katre]

Sadly not. It's a good idea but it hasn't been prioritized and I don't have enough time to work on it as background.

[Silic0nS0ldier]

Is there sufficient capacity to support a community-driven implementation of this? ("this" being the "Execution Platforms vs. Strategies" proposal, which includes resolving this issue)

[katre]

I'd be happy to support a community-driven implementation. My worry currently is that the previous proposal is fairly old, and could probably use a rewrite to update it and provide clarity with new features.

[Silic0nS0ldier]

It still needs more work (polish, expanding on background, etc) but since I've got a functional prototype I figured it worth sharing.

bazelbuild/proposals#359

Compared to the Strategy Properties on Platforms proposal;

1. It does not replace the existing spawn strategy controls.
2. Existing spawn strategy flags --spawn_strategy (default), --strategy (mnemonic) and --strategy_regexp (regex match action description) are expanded to allow platform targeting.

Source for the prototype is at Silic0nS0ldier#5, if a platform is referenced by an alias (assuming that can be done) it won't work.