add workspace environment support #20900
Conversation
| # TODO: This is necessary for tests of `adhoc_tool` and `shell_command` with | ||
| # workspace execution to pass repeatedly in local Pants development. | ||
| # We need a viable solution instead of this hack. | ||
| cache_scope=ProcessCacheScope.PER_SESSION, |
There was a problem hiding this comment.
@benjyw: Any ideas on how to fix the test caching issue in the Pants repository and avoid this hack?
|
Only the most recent commit is new. The other commits are from #20772. |
tdyas
force-pushed
the
shell_workspace_support_2
branch
2 times, most recently
from
40dd9d4
to
2808018
Compare
tdyas
force-pushed
the
shell_workspace_support_2
branch
3 times, most recently
from
66e9416
to
3387cae
Compare
| @@ -253,6 +254,33 @@ class AdhocToolOutputRootDirField(StringField): | |||
| ) | |||
|
|
|||
|
|
|||
| class AdhocToolCacheScopeField(StringField): | |||
There was a problem hiding this comment.
Introduction of cache scope to adhoc_tool and shell_command target types should be moved to a separate PR if we decide to keep it. It was necessary to provide a way for tests to set cache_scope to ProcessCacheScope.PER_SESSION in order to avoid cached results from prior tests runs from being used for a current test run.
This points to a more fundamental problem: Will workspace executions which modify the workspace be inherently a problem if the user is looking for them to always execute?
| # HACK: For workspace environments, the `find_binary.sh` will be mounted in the "chroot" directory | ||
| # which is not the current directory (since the process will execute in the workspace). Thus, | ||
| # adjust the path used as argv[0] to find the script. | ||
| script_name = "find_binary.sh" | ||
| script_exec_path = ( | ||
| f"./{script_name}" | ||
| if not env_target.is_workspace_environment() | ||
| else f"{{chroot}}/{script_name}" | ||
| ) |
There was a problem hiding this comment.
Is there a better way to handle this subtle difference between workspace environments and every other kind of environment? I believe remote environments do not support the {chroot} replacement so simply using {chroot}/find_binary.sh as the path won't work for all environments.
tdyas
force-pushed
the
shell_workspace_support_2
branch
from
3387cae
to
d5286e8
Compare
tdyas
force-pushed
the
shell_workspace_support_2
branch
from
d5286e8
to
350d7cf
Compare
Add support for a "workspace environment" which is similar to a local environment except that execution happens in the repository itself (i.e., the "workspace") and not in an execution sandbox. This implements the user-visible experience of Design B from the "In-Workspace Process Execution" design document.
This PR builds on top of the Rust support for in-workspace execution contained in #20772.
Users will use the new
workspace_environmenttarget type to configure workspace execution support.The pants-workspace-exec-testing repository contains an example of how to use this support to allow Pants to invoke Bazel in the workspace.