Skip to content
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

Pass default_shell_env through actions #502

Closed
wants to merge 1 commit into from

Conversation

keith
Copy link
Member

@keith keith commented Oct 8, 2020

Through the investigation of
bazelbuild/bazel#12049 one of the things I
discovered was that when using actions.run there are 2 options for
environment variables. use_default_shell_env = True is recommended,
but cannot be used if you want to also pass env to the actions. To
support Xcode version selection we have to pass env with those
variables. Without the default shell env, we only get the environment
variables defined in the crosstool, but not those passed with
--action_env. This now adds variables passed as
--action_env=FOO=BAR, but not those passed as --action_env=FOO
(where the value is supposed to pass through).

This is useful to ensure a few things:

  1. The default PATH things are executed with includes /usr/local/bin.
    This can result in pollution of binaries from homebrew. Previously
    there was no way to limit this
  2. This should be a good replacement for using custom Swift toolchains.
    Currently those environment variables only apply to some actions
    (excluding those from bazel) using --action_env=TOOLCHAINS=foo
    should work better than the current solution (this change can be made
    as a followup)

@segiddins
Copy link
Contributor

So I was thinking of an alternative -- instead of trying to merge in the configuration's default shell env, what if we used env to add in the env vars we want, and call the executables that way?

@keith
Copy link
Member Author

keith commented Oct 8, 2020

Use which env to add them where?

@segiddins
Copy link
Contributor

/usr/bin/env FOO=BAR ... -- executable args...

@keith
Copy link
Member Author

keith commented Oct 8, 2020

ah, I think piping that through would probably be a bit more difficult than this. I'm not sure we want to compete with bazel's logic for this

Through the investigation of
bazelbuild/bazel#12049 one of the things I
discovered was that when using `actions.run` there are 2 options for
environment variables. `use_default_shell_env = True` is recommended,
but cannot be used if you want to also pass `env` to the actions. To
support Xcode version selection we have to pass `env` with those
variables. Without the default shell env, we only get the environment
variables defined in the crosstool, but not those passed with
`--action_env`. This now adds variables passed as
`--action_env=FOO=BAR`, but not those passed as `--action_env=FOO`
(where the value is supposed to pass through).

This is useful to ensure a few things:

1. The default PATH things are executed with includes /usr/local/bin.
   This can result in pollution of binaries from homebrew. Previously
   there was no way to limit this
2. This should be a good replacement for using custom Swift toolchains.
   Currently those environment variables only apply to some actions
   (excluding those from bazel) using `--action_env=TOOLCHAINS=foo`
   should work better than the current solution (this change can be made
   as a followup)
@brentleyjones brentleyjones force-pushed the ks/pass-default_shell_env-through-actions branch from d2c1579 to c5b0e71 Compare June 4, 2021 19:09
@brentleyjones
Copy link
Collaborator

FYI: I've been using this with --action_env=TOOLCHAINS=$TOOLCHAINS to great effect.

@keith keith marked this pull request as ready for review June 4, 2021 19:15
@keith
Copy link
Member Author

keith commented Sep 19, 2023

#1114

@keith keith closed this Sep 19, 2023
@keith keith deleted the ks/pass-default_shell_env-through-actions branch September 19, 2023 22:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants