-
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
testing.TestEnvironment not equal to itself #15225
Comments
|
Related, I would love a way to query for the bazel/src/main/java/com/google/devtools/build/lib/starlarkbuildapi/test/TestingModuleApi.java Line 52 in ee9727d
Edit: And I see you filed that already: #15224 ❤️ |
It seems surprising to me that it wouldn't compare equal to itself, unless a new method descriptor is being created each time the method is retrieved. But I thought we cached those. |
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
* 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); ^ ```
Description of the bug:
The
testing.TestEnvironment
object is a bit strange: it isn't equal to itself. In comparison, most provider keys are equal to themselves.This makes it difficult to write code that can properly detect when the testing.TestEnvironment provider key was requested, e.g.
(in my particular case, I'm writing helper code for tests to assert TestEnvironment)
Also, I'm not sure if this should be TestEnvironment or TestEnvironmentInfo -- the public symbol is
testing.TestEnvironment
, but the docs say it returnsTestEnvironmentInfo
(note no leading "testing" namespace and the extra Info suffix).What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
actual: prints false
expected: prints true
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.n/a
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?
15224 is sort of related -- same category of "TestEnvironemt provider acts weird"
Any other information, logs, or outputs that you want to share?
No response
The text was updated successfully, but these errors were encountered: