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

env attribute of *_test rules should be able to overwrite variables like PATH #14418

Closed
martis42 opened this issue Dec 13, 2021 · 8 comments
Closed
Labels
P4 This is either out of scope or we don't have bandwidth to review a PR. (No assignee) team-Rules-Server Issues for serverside rules included with Bazel type: feature request

Comments

@martis42
Copy link

Description of the problem / feature request:

The test rule attribute env should be able to overwrite environment variables, not just inject additional ones.

Feature requests: what underlying problem are you trying to solve with this feature?

I am writing tests which require a custom PATH value.
One could modify the PATH environment variable inside the test implementation, but I consider this a hacky workaround.

--test_env can do the required task, but it influences all tests, whereas I want to influence just some specific tests.

Bugs: what's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

BUILD file

sh_test(
    name = "foo",
    srcs = ["foo.sh"],
    env = {
        "PATH": "foo",
        "FOO": "bar",
    },
)

test implementation

#!/usr/bin/env bash
echo $PATH
echo $FOO

command: bazel test --test_output=all //:foo

The test will not print the expected foo.

What operating system are you running Bazel on?

Ubuntu 20.04

What's the output of bazel info release?

release 4.1.0

Have you found anything relevant by searching the web?

The documentation explicitly states Specifies additional environment ....
It seems the current behavior is intended. Still, I believe being able to overwrite PATH is a valid feature.
No open issues discussing overwriting environment variables could be found.

@aiuto aiuto added untriaged team-Local-Exec Issues and PRs for the Execution (Local) team labels Dec 18, 2021
@meisterT meisterT added team-Core Skyframe, bazel query, BEP, options parsing, bazelrc and removed team-Local-Exec Issues and PRs for the Execution (Local) team labels Dec 20, 2021
@janakdr janakdr added team-Rules-Server Issues for serverside rules included with Bazel and removed team-Core Skyframe, bazel query, BEP, options parsing, bazelrc labels Dec 25, 2021
@janakdr
Copy link
Contributor

janakdr commented Dec 25, 2021

Looks like this is only an issue with native tests, passing over to server rules team to make a policy decision. Hopefully this problem goes away since Starlark doesn't use this mechanism in any case?

@martis42
Copy link
Author

@janakdr Does this mean we will lose this feature completely when the language specific rules are migrated to Starlark? This would surprise me since the env and env_inherit attributes are recent additions from Bazel 4.0.0. I would have hoped the Starlark based rules will gain this feature as well eventually.

@janakdr
Copy link
Contributor

janakdr commented Dec 28, 2021 via email

@comius comius added P4 This is either out of scope or we don't have bandwidth to review a PR. (No assignee) and removed untriaged labels Aug 24, 2022
Copy link

github-actions bot commented Feb 7, 2024

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 1+ years. It will be closed in the next 90 days unless any other activity occurs. If you think this issue is still relevant and should stay open, please post any comment here and the issue will no longer be marked as stale.

@github-actions github-actions bot added the stale Issues or PRs that are stale (no activity for 30 days) label Feb 7, 2024
@martis42
Copy link
Author

martis42 commented Feb 7, 2024

The issue is still relevant and unresolved

@github-actions github-actions bot removed the stale Issues or PRs that are stale (no activity for 30 days) label Feb 8, 2024
@mgottscho
Copy link

+1 to this request.

@brentleyjones
Copy link
Contributor

@comius I think this should be higher than a P4.

keith added a commit to keith/bazel that referenced this issue May 16, 2024
keith added a commit to keith/bazel that referenced this issue May 16, 2024
@keith
Copy link
Member

keith commented May 16, 2024

I submitted #22420 to fix this

keith added a commit to keith/bazel that referenced this issue May 16, 2024
bazel-io pushed a commit to bazel-io/bazel that referenced this issue May 21, 2024
Fixes bazelbuild#14418

Closes bazelbuild#22420.

PiperOrigin-RevId: 635740423
Change-Id: Iffd4d172c4175be2e1b6cfad04ddad2759adb987
github-merge-queue bot pushed a commit that referenced this issue May 21, 2024
Fixes #14418

Closes #22420.

PiperOrigin-RevId: 635740423
Change-Id: Iffd4d172c4175be2e1b6cfad04ddad2759adb987

Commit
01a90d6

Co-authored-by: Keith Smiley <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
P4 This is either out of scope or we don't have bandwidth to review a PR. (No assignee) team-Rules-Server Issues for serverside rules included with Bazel type: feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants