Versions
SonarQube Server version - Enterprise Edition v9.9.6 (build 92038)
Sonar scanner - sonar-scanner-cli-7.0.2.4839-Linux-X64
Build wrapper - version 6.41.2 (linux-x86)
What works so far
Hi, I am trying to analyze a C++ project in a Github workflow. The project is built as an ubuntu container and the runner(host) building it, is also ubuntu.
So far it is working with the following method:
- Download build wrapper and sonar scanner using sonarsource/sonarqube-github-c-cpp@v2.1.0 action on the runner
- Start the docker build
- Use the build wrapper during build in the container
- Use the sonar scanner in the container
This all works because both tools are used inside the same environment. It has created a bit of a mess in the Dockerfile as well, separating two builds, one for scanning and one for release
The problem
My team has noticed that there’s a warning when the download action is used stating Warning: This action is deprecated and will be removed in a future release. Please use the sonarqube-scan-action and its install-build-wrapper sub-action instead.
So we investigated and tried to setup the new approach.
We have another C++ project that uses sonar as well, but that one is built normally, outside of a container and everything went smooth there.
The problem is that with the new approach it seems imposible to analyze the dockerized project. Since the sonar scanner is run as an action the environment for build and the environment for scanning are different and the scanner dislikes that.
What I’ve tried
The runner already has the source files. I’ve also exported the build directory of the container to the runner, thus providing the scanner with everything that was built and it still didn’t work properly, giving the following output
09:23:01.264 INFO EXECUTION FAILURE
09:23:01.265 INFO Total time: 10.006s
09:23:01.265 ERROR Error during SonarScanner CLI execution
java.lang.IllegalStateException: The "build-wrapper-dump.json" file was found but 0 C/C++/Objective-C files were analyzed. Please make sure that:
* you are using the latest version of the build-wrapper and the CFamily analyzer
* you are correctly invoking the scanner with correct configuration
* your compiler is supported
* you are wrapping your build correctly
* you are wrapping a full/clean build
* you are providing the path to the correct build-wrapper output directory
* you are building and analyzing the same source checkout, absolute paths must be identical in build and analysis steps
at com.sonar.cpp.plugin.CFamilySensor.process(CFamilySensor.java:494)
at com.sonar.cpp.plugin.CFamilySensor.execute(CFamilySensor.java:215)
at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(AbstractSensorWrapper.java:64)
at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:88)
at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(ModuleSensorsExecutor.java:64)
at org.sonar.scanner.scan.SpringModuleScanContainer.doAfterStart(SpringModuleScanContainer.java:82)
at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:188)
at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:167)
at org.sonar.scanner.scan.SpringProjectScanContainer.scan(SpringProjectScanContainer.java:403)
at org.sonar.scanner.scan.SpringProjectScanContainer.scanRecursively(SpringProjectScanContainer.java:399)
at org.sonar.scanner.scan.SpringProjectScanContainer.doAfterStart(SpringProjectScanContainer.java:368)
at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:188)
at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:167)
at org.sonar.scanner.bootstrap.SpringGlobalContainer.doAfterStart(SpringGlobalContainer.java:137)
at org.sonar.core.platform.SpringComponentContainer.startComponents(SpringComponentContainer.java:188)
at org.sonar.core.platform.SpringComponentContainer.execute(SpringComponentContainer.java:167)
at org.sonar.batch.bootstrapper.Batch.doExecute(Batch.java:72)
at org.sonar.batch.bootstrapper.Batch.execute(Batch.java:66)
at org.sonarsource.scanner.lib.internal.batch.BatchIsolatedLauncher.execute(BatchIsolatedLauncher.java:41)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.base/java.lang.reflect.Method.invoke(Unknown Source)
at org.sonarsource.scanner.lib.internal.facade.inprocess.IsolatedLauncherProxy.invoke(IsolatedLauncherProxy.java:62)
at jdk.proxy3/jdk.proxy3.$Proxy2.execute(Unknown Source)
at org.sonarsource.scanner.lib.internal.facade.inprocess.InProcessScannerEngineFacade.doAnalyze(InProcessScannerEngineFacade.java:38)
at org.sonarsource.scanner.lib.internal.facade.AbstractScannerEngineFacade.analyze(AbstractScannerEngineFacade.java:66)
at org.sonarsource.scanner.cli.Main.analyze(Main.java:79)
at org.sonarsource.scanner.cli.Main.main(Main.java:64)
A bit before the error I see these types of messages
09:23:01.220 WARN Invalid probe found, skip analysis of files: [/path/to/sources/implementation.cpp]
The compiler probe 'stdout' is expected to contain at least one '#define' directive:
For most of my cpp files.
I’ve made sure that the absolute paths of the docker container match those of the runner.
Questions
-
How to analyze dockerized C++ code?. Even if the above example somehow works it’s such a hacky way to analyze it. We also have Go code in containers and there the process is much more elegant.
-
Will the old way be deleted and if so, when? - This is crucial to us, because we don’t want to end up in a situation where the old version doesn’t work and we haven’t implemented the new one.