[7.0.0] Regression in 7.0.0rc4: singlejar doesn't follow symbolic link (after flip of --incompatible_sandbox_hermetic_tmp option per default)
#20262
Comments
|
@bazel-io flag |
bazel-io
added
the
potential release blocker
davido
changed the title
--incompatible_sandbox_hermetic_tmp option per default)
davido
changed the title
--incompatible_sandbox_hermetic_tmp option per default)singlejar doesn't follow symbolic link (after flip of --incompatible_sandbox_hermetic_tmp option per default)
|
Cc @cushon |
|
Cc @lberki since Gerrit seems to have a working directory under |
|
@bazel-io fork 7.0.0 |
bazel-io
removed
the
potential release blocker
|
I'm not seeing strong evidence that this is a singlejar bug, vs. it accurately reporting that it's being given a path that doesn't exist when With With
|
|
Thanks for the investigation! @lberki I unfortunately won't be able to look into this in more detail this week. In order to not block the release, I could see either unflipping the flag or reverting to the state where it just disabled itself if a source root was under |
|
I don't think this is an issue with the sources being under Suggestions:
|
|
@davido Would any of the suggestions work for you? |
|
Thanks for investigation and workaround suggestions. |
|
Thanks, then I'll close this one. |
Description of the bug:
After upgrading Bazel from 7.0.0rc3 to 7.0.0rc4 trying to build Gerrit plugin, that is linked to the Gerrit workspace per symbolic link, stopped working:
With the --sandbox_debug, this additional output is issued:
In bazel 7.0.0rc3 it works as expected.
In the above example, the actually location of the oauth-plugin:
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.
Clone gerrit recursively say in
$HOME/projects/gerrit.Clone gerrit-oauth plugin say in
$HOME/projects/oauth.Create symbolic link in gerrit's plugin directory:
Copy
external_plugin_deps.bzlfrom oauth Workspace in gerrit/plugins directory:Try to build the plugin with 7.0.0rc4, using this CL: [1]
Important, make sure, that the parent change is also included: [2], to unflip
--enable-bzlmodbit.Build
gerrit-oauthplugin in gerrit workspace mode like this:[1] https://gerrit-review.googlesource.com/c/gerrit/+/387360
[2] https://gerrit-review.googlesource.com/c/gerrit/+/393394
Which operating system are you running Bazel on?
Linux
What is the output of
bazel info release?7.0.0.rc4
If
bazel info releasereturnsdevelopment versionor(@non-git), tell us how you built Bazel.No response
What's the output of
git remote get-url origin; git rev-parse master; git rev-parse HEAD?No response
Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.
Yes, it's a regression, it works as expected in Bazel 7.0.0rc3.
It seems to be related to
--incompatible_sandbox_hermetic_tmpoption flip per default in:#19943
Have you found anything relevant by searching the web?
This issue seems to be related.
Any other information, logs, or outputs that you want to share?
Related build rule in oauth-plugin is:
This rule is expanded to:
Currently, there are four workarounds:
resourcesattribute fromgerrit_pluginmacro. This would corrupt plugin artifact and is not an option:Avoid using symbolik links. But we use this feature since Bazel 0.2 and would like to preserve that feature. Also note, that all Gerrit plugins that use
resourcesattribute ingerrit_pluginmacro are affected.Unflip the option:
--incompatible_sandbox_hermetic_tmp, by saying:bazeldev build --noincompatible_sandbox_hermetic_tmp plugins/oauthPass
--sandbox_add_mount_pair=/tmpoption.The text was updated successfully, but these errors were encountered: