You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is very useful to have the flag --remote-execution as a quick CLI toggle for RE. For example, when you're on a plane, you want to disable RE without having to rewrite all of your BUILD files to change the environment= they are set to.
I tried to implement that logic inside our rules that set up the Platform, CompleteEnvironmentVars, and ProcessConfigFromEnvironment: ca3c581. But I realized this was not a valid approach. While that commit "fixes" those 3 types to use the local environment, the env vars and executable search paths would still be coming from the remote_environment target, rather than the local_environment target, which is an error.
Instead, the fallback must live one level higher, in our rule that determines which environment name should be used via "matcher" logic:
This solves several problems we had with remote execution:
1. You can now specify different env vars than localhost, #7735
2. You can now mix remote execution with Docker execution from #13682
3. You can have multiple configurations for the remote execution server, which is particularly useful so you can specify different Docker images to run in remote execution.
If you are not yet using the environments mechanism, then remote execution continues to be toggled via the `--remote-execution` option. Otherwise, remote execution is only used when a remote execution environment target is used. Follow up work will re-evaluate this by leveraging "environment matchers". See #16907 for more info.
A follow up will add the `extra_platform_properties` field (#16908).
It is very useful to have the flag
--remote-execution
as a quick CLI toggle for RE. For example, when you're on a plane, you want to disable RE without having to rewrite all of your BUILD files to change theenvironment=
they are set to.I tried to implement that logic inside our rules that set up the
Platform
,CompleteEnvironmentVars
, andProcessConfigFromEnvironment
: ca3c581. But I realized this was not a valid approach. While that commit "fixes" those 3 types to use the local environment, the env vars and executable search paths would still be coming from theremote_environment
target, rather than thelocal_environment
target, which is an error.Instead, the fallback must live one level higher, in our rule that determines which environment name should be used via "matcher" logic:
pants/src/python/pants/core/util_rules/environments.py
Lines 336 to 339 in 8923ea2
The text was updated successfully, but these errors were encountered: