The documentation marks it as a requirement to disable Bazel sandboxing in order for the build-wrapper to work: https://docs.sonarqube.org/latest/analysis/languages/cfamily/#header-9
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: https://kchodorow.com/2016/07/08/the-mixed-up-directories-of-mrs-bazel-e-frankweiler/
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 sonar-project.properties 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 sonar-project.properties 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.