-
-
Notifications
You must be signed in to change notification settings - Fork 646
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Set the entire env in __run.sh #18582
Conversation
This happens e.g., in lint/fmt, where we don't pass env vars.
Please double-check my Rust, as I am just fumbling along there still. |
export
line in __run.sh.cd {stringified_cwd} | ||
{stringified_command_line} | ||
env -i {stringified_env_vars} {stringified_command_line} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've done this by hand myself reproing user issues and it worked fine. Did you double check this still works?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep, ran a few different command (test, lint, fmt) with --keep-sandboxes=always
, cd'd into the sandbox and ran __run.sh
to ensure that the process still does the thing we expect it to do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just checked env -i bash -c 'echo $HOME.'
-> ".", but I did not gut check a sandbox __run.sh
using this change.
Previously we set the explicit env vars passed to the Process on top of the existing env.
Now we use
env -i
to force the process to run with exactly the same env as it didin the engine. This will create a much more faithful debugging setup when you poke
around in the sandbox and run
__run.sh
.