Prevent a crash when using --repo_env=VAR without a value #12886
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The --repo_env option is documented in the same way as --action_env. In
addition to allowing you to set explicit values, you can also use it to
explicitly pick values from the environment in which Bazel was invoked.
Unfortunately, this causes a null pointer exception in Starlark due to a
null string stored as a map value.
This change extends the logic of converting --repo_env to a map to take
null values into account. When null, the value is loaded from the
current environment. This behaviour is useful in case you want to do
something like this:
--incompatible_strict_action_env --action_env=PATH=... --repo_env=PATH
This allows you to run build actions with a strict value for $PATH (e.g.,
to get a decent action cache hit rate in case of remote execution),
while still allowing repository_ctx.which() to find tools on the host
system using $PATH.