-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Allow testing.TestEnvironment / TestEnvironmentInfo to be read from Starlark #15224
Comments
meteorcloudy
added
team-Build-Language
and removed
team-OSS
Issues for the Bazel OSS team: installation, release processBazel packaging, website
labels
Apr 13, 2022
At a glance, it looks like this provider is consumed natively but indeed not accessible from Starlark. The above example fails because the |
brandjon
changed the title
testing.TestEnvironment / TestEnvironmentInfo cannot be read from a target
Allow testing.TestEnvironment / TestEnvironmentInfo to be read from Starlark
Apr 28, 2022
brandjon
added
P4
This is either out of scope or we don't have bandwidth to review a PR. (No assignee)
and removed
untriaged
labels
Apr 28, 2022
fmeum
added a commit
to fmeum/bazel
that referenced
this issue
Jun 29, 2022
The new RunEnvironmentInfo provider allows any executable or test Starlark rule to specify the environment for when it is executed, either as part of a test action or via the run command. Refactors testing.TestEnvironment to construct a RunEnvironmentInfo and adds a warning (but not an error) if the provider constructed in this way is returned from a non-executable non-test rule. If a RunEnvironmentInfo is constructed directly via the Starlark constructor, this warning becomes an error. Fixes bazelbuild#7364 Fixes bazelbuild#15224 Fixes bazelbuild#15225 Closes bazelbuild#15232. PiperOrigin-RevId: 448185352
ckolli5
pushed a commit
that referenced
this issue
Jun 29, 2022
* Specify fixedEnv/inheritedEnv interaction in ActionEnvironment Previously, ActionEnvironment did not publicly document how fixed and inherited environment variables interact, but still cautioned users to keep the two sets disjoint without enforcing this. As a result, neither could users rely on the interaction nor could ActionEnvironment benefit from the additional freedom of not specifying the behavior. With this commit, ActionEnvironment explicitly specifies that the values of environment variable inherited from the client environment take precedence over fixed values and codifies this behavior in a test. This has been the effective behavior all along and has the advantage that users can provide overrideable defaults for environment variables. Closes #15170. PiperOrigin-RevId: 439315634 * Intern trivial ActionEnvironment and EnvironmentVariables instances When an ActionEnvironment is constructed out of an existing one, the ActionEnvironment and EnvironmentVariables instances, which are immutable, can be reused if no variables are added. Also renames addVariables and addFixedVariables to better reflect that they are operating on an immutable type. Closes #15171. PiperOrigin-RevId: 440312159 * Let Starlark executable rules specify their environment The new RunEnvironmentInfo provider allows any executable or test Starlark rule to specify the environment for when it is executed, either as part of a test action or via the run command. Refactors testing.TestEnvironment to construct a RunEnvironmentInfo and adds a warning (but not an error) if the provider constructed in this way is returned from a non-executable non-test rule. If a RunEnvironmentInfo is constructed directly via the Starlark constructor, this warning becomes an error. Fixes #7364 Fixes #15224 Fixes #15225 Closes #15232. PiperOrigin-RevId: 448185352 * Fix strict deps violation ``` src/main/java/com/google/devtools/build/lib/analysis/starlark/StarlarkRuleClassFunctions.java:990: error: [strict] Using type com.google.devtools.build.lib.cmdline.LabelValidator from an indirect dependency (TOOL_INFO: "//src/main/java/com/google/devtools/build/lib/cmdline:LabelValidator"). See command below ** LabelValidator.parseAbsoluteLabel(labelString); ^ ```
JamesMBartlett
added a commit
to JamesMBartlett/rules_go
that referenced
this issue
Aug 22, 2022
Works the same as the `go_cross_binary` rule. Because of [this](bazelbuild/bazel#15224) bazel issue, there's no way to access the underlying `go_test` rule's `env` info provider. So until bazel 5.3.0 becomes the `rules_go` minimum bazel version, I see no way of passing through the `go_test` rule's `env` to the `go_cross_test`. This means any `env` set will not be used when the `go_cross_test` test is run, which is a little unfortunate. However, I think `go_cross_test` is still useful in the meantime despite this limitation. Signed-off-by: James Bartlett <jamesbartlett@newrelic.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Description of the bug:
Given a target that returns the testing.TestEnvironment / TestEnvironmentInfo, that provider cannot be read from the target.
This makes it impossible to easily test that the rule constructs an appropriate TestEnvironmentInfo object.
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
Actual behavior:
An error like below occurs:
Expected behavior:
The TestEnvironmentInfo provider instance is returned.
Which operating system are you running Bazel on?
Linux
What is the output of
bazel info release
?google build
If
bazel info release
returnsdevelopment version
or(@non-git)
, tell us how you built Bazel.Google build
What's the output of
git remote get-url origin; git rev-parse master; git rev-parse HEAD
?Have you found anything relevant by searching the web?
None found
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: