Build-wrapper-output.bypass alternative

  • ALM used (GitHub, Bitbucket Cloud, Azure DevOps)

Azure DevOps

  • CI system used (Bitbucket Cloud, Azure DevOps, Travis CI, Circle CI

Azure DevOps

  • Scanner command used when applicable (private details masked)
/__w/_tasks/SonarCloudAnalyze_ce096e50-6155-4de8-8800-4221aaeed4a1/1.27.0/sonar-scanner/bin/sonar-scanner
  • Languages of the repository
- C++
- Python
  • Error observed (wrap logs/code around with triple quotes ``` for proper formatting)
##[error]ERROR: Error during SonarScanner execution
java.lang.IllegalStateException: The "build-wrapper-dump.json" file was found but 0 C/C++/Objective-C files were analyzed.
  • Steps to reproduce
- Build source code with build wrapper
- Exclude sources using `sonar.exclusions=`
  • Potential workaround
- Check whether there are included sources in the build-wrapper-output.json
- Set the `sonar.cpp.file.suffixes` to `-` if there are none
- Set the `sonar.cfamily.build-wrapper-output` to `` if there are none

So we have a repository with multiple packages of c++ and python and we are also building some c++ dependencies. Our build system resolves what code is modified and only builds the modified package with its dependencies.

the problem

We have a python package that we would like to analyse that depends on a c++ package (external). This external c++ package is compiled since we need in in our python package but the sources are excluded from the analyses since we are only interested in analyses on our sources.

Now the sonar scanner throws the above mentioned error but this is expected. How can we work around this properly? There used to be a build-wrapper-output.bypass settings but this was removed. But, this was exactly what we needed.

Hey there.

If you are excluding the C++ files from analysis… why run the build wrapper at all? You can just run the scanner to cover your Python files, while excluding the C++ files.

Hi Colin,

Thanks for your reply. We also have c++ packages and we detect what package is modified and rebuild that package with its dependencies. We are using ros that allows mixing c++ and python packages so the build script does not know whether a package is c++ or python.

Hello @reinzor,

We are not suggesting that you don’t build C++ & Python together. What we are suggesting is that you build them, but without involving the build-wrapper at all. This tool is only there for the C++ analysis. If you don’t need C++ analysis, you don’t need the build wrapper.

We also have C++ package that we would like to get analyzed, that is why we are using the build wrapper when invoking our workspace builder catkin tools.

I understand what you are saying but this would imply we cannot use our present catkin tools workspace builder for building ros packages. As far as I understand here, there is no simple solution for this then. So we will work around this by parsing the build-wrapper output.

Hello @reinzor,

I’m not sure what you exactly want. Let me try to summarize what I think I understood of your situation:

  • You have a mix of C++ & Python projects, they all have to be built together
  • Among the C++ projects, some should be analyzed, some should not. You use exclusions to specify that
  • Your build system is incremental, so some projects may be skipped
  • In the situation that all C++ projects to analyze are excluded, the analysis fails.

Am I right? Did I miss something?

If yes, then there is a major issue with this situation: To be able to correctly track issues, we have to analyze all C++ code each, even if it has not changed. If you skip some projects from time to time, the detection of new code will stop working.

Now, when we say you have to analyze all the C++ code each time, this does not have to be long:

  • It you cache the analysis results, you can enable caching by setting sonar.cfamily.cache.enabled=true and correctly setting sonar.cfamily.cache.path to the cache folder.
  • You still need to provide configuration for all the files in all your projects. The build wrapper is not the right tool here, you should use a compilation database (I assume you have a version recent enough to support it). Then, you are on your own to create it, and either your build tools can regenerate it during the build without actually building, or you can cache it between builds.

Hope this helps,