Bazel sandbox and SonarQube build-wrapper

The documentation marks it as a requirement to disable Bazel sandboxing in order for the build-wrapper to work:

I do not understand the reasoning though.

so that the compiled file paths could be retrieved after the compilation phase

But indeed, with the sandbox I get an empty SonarQube report (without the SCA findings) while without it the reports are fine.

I analyzed the build-wrapper-dump and was surprised that they are almost identical.
The only main difference is that the “cwd” attribute refers to another path in the Bazel cache of course.

In the sandboxed way it looks like this

Now the sandbox does not exist after the compilation step, and anything that’s not marked as a Bazel output is simply ignored and lost.
While the non-sandboxed way actually creates a symlink and everything is preserved.
More on this here:

But this got us thinking, why would you need the cwd to point to something which exists. What do you need, which is not already in the build-wrapper dump or the file.
For example the properties actually list the sources:

So in the end I modified the build-wrapper dump to point to the actual sources in the cwd attribute and it works.

So this proves that disabling the sandboxing is not a requirement and the sonar-scanner does not need to check or do anything with the files it finds in the cwd attribute, as it’s already in the file.

Or is there anything we don’t see?
Why would we disable the Bazel sandbox?
The documentation is very minimal and could use some improvement I think.

Hi @otisonoza,

The fact that it doesn’t work should be evident for the reasoning.

For the analysis we need good build configuration in order to have the proper settings, this is why we collect build information.

We don’t want people to tamper the build-wrapper-dump.json file because if you do that you may miss include paths and have bad configuration for file analysis. Our objective is to provide something which works out of the box, without manual modification, we are build tool agnostic and we don’t differentiate between bazel, ninja, make, etc…

Thank you for the feedback.

(I’m working together with Ádám on this issue.)
So, apparently the SonarQube build-wrapper is expected to work out of the box, but users are expected to disable one of the key features of Bazel (sandboxed builds)? We use Bazel because it does sandboxed builds by default!

We want to help you, and found a way to make it work for us even with Bazel’s sandboxed builds. So we wonder what could be done to make it “work out of the box”, and started asking questions. Your replies to me reads as if you don’t want that help. I just cannot imagine this really is the case.

What information can we share so that you can help with our use case?

Best regards,
Micha Lenk