-
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
Preserve analysis cache through --test_env
changes
#24316
Conversation
Will mark as ready for merge (or merge myself) once the tests are fixed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I fixed the failing test.
@@ -329,7 +330,7 @@ public void exit(AbruptExitException exception) { | |||
} | |||
} | |||
for (Map.Entry<String, String> entry : | |||
options.getOptions(CoreOptions.class).testEnvironment) { | |||
options.getOptions(TestOptions.class).testEnvironment) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@katre I'm not 100% sure whether this will work as is - would build
and info
need to declare that they use TestOptions
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just add a check that TestOptions is present: if it's absent the entire block can be skipped.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm worried that it just won't ever be there for info
. The tests didn't trigger any crashes though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if you wrap the entire for loop in if (options.contains(TestOptions.class))
then it'll be safe for any command.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It will be safe in the sense of "doesn't crash", but will this still be a backwards compatible change in the sense that bazel info client-env
shows test env entries?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I was able to run a quick demo:
$ FOO=bar ~/repos/bazel/bazel-bin/src/bazel --host_jvm_debug info --test_env=FOO client-env
Running host JVM under debugger (listening on TCP port 5005).
build --test_env=FOO=bar
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice. In that case I would leave it as is so that we get a crash instead of silent loss of functionality if this ever breaks. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM.
@iancha1992 Could you mark this for 8.1.0? |
This was rolled-back at 1da4641 |
@katre Can you please check if what's the reason of the internal breakage? |
I'll investigate. |
Okay, it turns out that there are exactly three I'm going to look into whether it's possible to fix these. |
Would it be possible to mark them |
Using |
Can you rebase this on to HEAD and I'll try again? |
Sent #24398 |
Fixes #7450
RELNOTES[INC]: Changing --test_env no longer invalidates the analysis cache.
ctx.configuration.test_env
may be empty for non-test rules and should not be used by such rules.