-
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
Add multiplex sandboxing support for Java actions #21091
Comments
|
That did not work for me. Not sure if this is important, but the first time it fails, it doesn't print an error message, only these:
And then on a re-run it prints a message like the one in the original post. |
@DavidANeil Sorry, I think my instructions may not have been clear: Did you build Bazel from that PR and then used that |
Here are the commands I ran:
|
…ization `JavaHeaderCompileAction` can apply an optimization where it compiles the source files only against direct dependencies, making use of the fact that Turbine includes sufficient information about transitive dependencies into the direct header jars in a special directory. In order to ensure that downstream consumers of header compilation action can use its `.jdeps` file regardless of which of these actions actually uses path mapping, all such paths to transitive jars have to be unmapped. With this commit, actions can declare additional artifacts whose paths they want to apply path mapping to. By always passing all transitive jars into the path mapper, even when only the direct jars are inputs to the action, the transitive header jar paths can be unmapped and stripped path collisions between them correctly result in a noop `PathMapper` being used for the current action. Fixes bazelbuild#21091 Closes bazelbuild#19872. PiperOrigin-RevId: 604772306 Change-Id: I21d25785b2e909aace8554251f41b1012185138a
Reopening, I accidentally left the issue reference in the PR description even after you confirmed the error. Something seems to have regressed on master, I will investigate further. |
@DavidANeil Nvm, I forgot to mention that path mapping doesn't support the unsandboxed multiplex worker mode used by Java actions (see https://youtu.be/Et1rjb7ixUU?t=1300). Could you try again with |
Seems to build correctly. We use multiplexing for our Scala compiles, so I can't just disable that, would it make sense to re-title this issue, or open a new one, or is there an existing issue for tracking making the two features compatible? |
What I know is #19719 (comment). Feel free to update the title. @hvadehra Has the internal situation regarding sandboxed multiplexed Javac workers changed? Would you accept a PR along the lines of https://bazel-review.googlesource.com/c/bazel/+/179090 that adds support, possibly optional and/or for Bazel only? |
@wilwell I think you took this over from Lars? |
…th optimization (#21227) `JavaHeaderCompileAction` can apply an optimization where it compiles the source files only against direct dependencies, making use of the fact that Turbine includes sufficient information about transitive dependencies into the direct header jars in a special directory. In order to ensure that downstream consumers of header compilation action can use its `.jdeps` file regardless of which of these actions actually uses path mapping, all such paths to transitive jars have to be unmapped. With this commit, actions can declare additional artifacts whose paths they want to apply path mapping to. By always passing all transitive jars into the path mapper, even when only the direct jars are inputs to the action, the transitive header jar paths can be unmapped and stripped path collisions between them correctly result in a noop `PathMapper` being used for the current action. Fixes #21091 Closes #19872. Commit fd196bf PiperOrigin-RevId: 604772306 Change-Id: I21d25785b2e909aace8554251f41b1012185138a Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>
Hi @fmeum! Thanks for mentioning of this CL. Right now Lars is not working with Javac workers, so probably I am the POC for this CL. We have observed issues internally with enabling of Javac sandboxed multiplex workers. The largest issue was connected with Java plugins. In general we are not ready to push this change. Even pushing only in Bazel means that we need to support this feature, but it's not well tested and we are not sure about its behaviour. To end on a good note I want to say, that we are going to spend time for enabling Javac sandboxed multiplex workers this year, because we see large benefits from using multiplex workers, but probably it's gonna happen in second half of the year. |
@wilwell Thanks for the update! Glad to hear that this is at least on the roadmap. In the meantime, what do you think of merging just the JavaBuilder and worker part of the CL but not the changes to the Java toolchain setup that set the execution requirement? This way the feature wouldn't be enabled by default in Bazel, but interested users could already try it out via |
If it would be helpful to merge just the JavaBuilder parts of that, I can help with the reviews for that if you want to pick it up. Is it basically just the bazel/src/java_tools/buildjar/java/com/google/devtools/build/buildjar/JavaLibraryBuildRequest.java Lines 224 to 231 in 3bb5b3f
|
@iancha1992 This is actually a separate issue. Could you change the title to |
This does not include adding support to Java actions yet. Work towards bazelbuild#21091 Closes bazelbuild#21370. PiperOrigin-RevId: 613231195 Change-Id: I87e76d2cebed3075a1eedfd8445b910ebd7604b9
Javac actions gained support for multiplex sandboxing with rules_java 7.5.0, which makes it possible to test path mapping in this mode. Fixes bazelbuild#21091
Javac actions gained support for multiplex sandboxing with rules_java 7.5.0, which makes it possible to test path mapping in this mode. Fixes bazelbuild#21091 Closes bazelbuild#21837. PiperOrigin-RevId: 657111790 Change-Id: Ib08f2c0bc48d210cce013e328da0e871f73278aa
Javac actions gained support for multiplex sandboxing with rules_java 7.5.0, which makes it possible to test path mapping in this mode. Fixes #21091 Closes #21837. PiperOrigin-RevId: 657111790 Change-Id: Ib08f2c0bc48d210cce013e328da0e871f73278aa Commit 8e79fe0 Co-authored-by: Fabian Meumertzheim <fabian@meumertzhe.im>
A fix for this issue has been included in Bazel 7.3.0 RC1. Please test out the release candidate and report any issues as soon as possible. |
Description of the bug:
Which category does this issue belong to?
Java Rules
What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.
I can reproduce this in the bazel repository with
What is the output of
bazel info release
?release 7.0.0
The text was updated successfully, but these errors were encountered: