-
Notifications
You must be signed in to change notification settings - Fork 4.4k
Fix test execution OS logic #28038
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
base: master
Are you sure you want to change the base?
Fix test execution OS logic #28038
Conversation
|
@bazel-io fork 9.0.0 |
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.
Code Review
This pull request correctly determines the execution OS for tests by using the execution platform associated with the specific test execution group, rather than a default platform. The changes involve refactoring how the ActionOwner and its corresponding PlatformInfo are obtained and passed down to where the execution OS is needed. This fixes a bug where the wrong OS was assumed for tests with custom execution groups. The changes are well-structured and include new tests that validate the corrected logic for different scenarios, including exec_group on the test rule and ExecutionInfo from the implementation. The code is cleaner and more correct.
ed76374 to
0cffea6
Compare
24bb4be to
fad452c
Compare
|
@fmeum Could you please take a look at the failing checks? |
373ad61 to
ebe8285
Compare
|
@bharadwaj08-one Fixed! |
4a5ee51 to
17e9685
Compare
3562416 to
e3aa5f9
Compare
|
I'll bounce this over to @gregestren ; firstly, it's quite late here, secondly, he is much more familiar with the intricacies of platform selection than I am. Superficially, it looks good to me, but I'd rather someone say that non-superficially also. |
src/main/java/com/google/devtools/build/lib/remote/RemoteExecutionService.java
Outdated
Show resolved
Hide resolved
| ) | ||
| return [ | ||
| DefaultInfo(executable = script), | ||
| testing.ExecutionInfo(exec_group = "alternative_test"), |
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 guess the context is #15664.
Does ExecutionInfo need to be anything more than a reference to an exec group now? i.e. is requirements still important? The main difference is ExecutionInfo can dynamically set them in the rule implementation context?
This reads subtle to me. It'd be great to clarify the relationships in https://bazel.build/extending/exec-groups and/or https://bazel.build/reference/test-encyclopedia#execution-platform. And why one would choose one over the other.
Did a specific experience motivate this that exec groups couldn't handle?
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 not sure. To be honest, I think that #15664 should not have landed, at least not until test actions have become less special than they currently are. Note that the current PR doesn't touch that feature, it just ensures that the new logic works correctly when it's used.
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.
Acknowledged, and I realize this PR is just a fix. I was just trying to get a better intuition of the wider context.
The execution OS is determined by the specified test exec group, which can differ from the `test` exec group as well as the test rule's default execution group.
e3aa5f9 to
bc82e10
Compare
|
Windows CI failures might be relevant? |
|
@gregestren As far as I can tell these tests are failing because Bazel's integration test setup pretends that the host platform is Linux even when running tests on Windows. The logic in @lberki in case you have an idea :-) |
|
#28224 shows the failures with the proper host platform set. |
The execution OS is determined by the specified test exec group, which can differ from the
testexec group as well as the test rule's default execution group.Also rename some helper methods to make this class of bugs less likely and clean up
ConstraintConstantsto support themacosalias for thedarwinOS constraint value.