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

Prevent a crash when using --repo_env=VAR without a value #12886

Closed

Conversation

EdSchouten
Copy link
Contributor

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.

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.
@google-cla google-cla bot added the cla: yes label Jan 22, 2021
@EdSchouten
Copy link
Contributor Author

Friendly ping!

@EdSchouten EdSchouten mentioned this pull request Feb 26, 2021
9 tasks
@jin jin added team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file. team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website labels Mar 1, 2021
@bazel-io bazel-io closed this in 3ebf658 Mar 12, 2021
philwo pushed a commit that referenced this pull request Mar 15, 2021
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.

Closes #12886.

PiperOrigin-RevId: 362506900
philwo pushed a commit that referenced this pull request Mar 15, 2021
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.

Closes #12886.

PiperOrigin-RevId: 362506900
@philwo philwo removed the team-OSS Issues for the Bazel OSS team: installation, release processBazel packaging, website label Nov 29, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cla: yes team-ExternalDeps External dependency handling, remote repositiories, WORKSPACE file.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants