Why does sonar cloud load project repositories 404 report an error?

[freeeyes]

• ALM used (GitHub, Bitbucket Cloud, Azure DevOps)
  GitHub: GitHub - ArkNX/PSS_ASIO: This is a plug-in IO interface management system, you can complete the separation of IO and logic through configuration files and writing plug-ins. Simplify your server development.
• CI system used (Bitbucket Cloud, Azure DevOps, Travis CI, Circle CI
  used Travis CI Travis CI - Test and Deploy with Confidence
• Scanner command used when applicable (private details masked)
  used sonar-project.properties

sonar.projectKey=PSS_ASIO
sonar.organization=openark
sonar.projectName=PSS_ASIO
sonar.projectVersion=3.0

sonar.sources=./PSS_ASIO
sonar.cfamily.build-wrapper-output=bw-output
sonar.cfamily.threads=2
sonar.cfamily.cache.enabled=false

• Languages of the repository
  C++
• Error observed (wrap logs/code around with triple quotes ``` for proper formatting)
  Travis CI - Test and Deploy with Confidence

java.lang.IllegalStateException: The "build-wrapper-dump.json" file was found empty. Please make sure that:
you are using the latest version of the build-wrapper and the CFamily analyzer
your compiler is supported
you are wrapping your build correctly
you are wrapping a full/clean build
if you are building your project inside a Docker container, build-wrapper is wrapping the build process inside the container and not wrapping the external Docker process
at com.sonar.cpp.plugin.CFamilySensor.execute(CFamilySensor.java:431)

• Steps to reproduce

Why does Get 404 report an error? Cause the subsequent analysis to fail?
How should I solve such a problem？
thanks.

[TomVanBraband]

Hello @freeeyes,

It seems like the projectKey you provided is not correct. I think you are trying to analyse this project and it’s key is ArkNX_PSS_ASIO not PSS_ASIO.

However that doesn’t seem to be related to what the scanner is failing on, I suspect it is failing because of it is not wrapping a full build (like is mentioned in the error message).
You are building your project prior to executing the build-wrapper, which probably means that the build-wrapper is not wrapping a full build.

[freeeyes]

@TomVanBraband thank you very much for your help.
I compared the test cases you provided

SonarSource/sonarcloud_example_cpp-cmake-linux-travis

• build-wrapper-linux-x86-64 --out-dir bw-output cmake --build build/

my travis.yml:

• build-wrapper-linux-x86-64 --out-dir bw-output cmake --build Build/Linux/

travis log:
$ build-wrapper-linux-x86-64 --out-dir bw-output cmake --build …/Build/Linux/
[ 79%] Built target pss_asio
[ 91%] Built target Test_Logic
[100%] Built target PacketParse_Inferface
The command “build-wrapper-linux-x86-64 --out-dir bw-output cmake --build …/Build/Linux/” exited with 0.

Is my path “Build/Linux/” incorrect?

[freeeyes]

@TomVanBraband
thanks，I solved the problem of incomplete compilation. And know the cause of the problem.
I generated build-wrapper-dump.json, but the sonar scan still reports errors.

An error occurred while analyzing the following compilation unit:

/home/travis/build/ArkNX/PSS_ASIO/PSS_ASIO/PSS_ASIO.cpp
A file named “sonar-cfamily-reproducer.zip” has been generated to help the problem investigation.
Please contact SonarSource support providing the following file to help improving the analyzer:
/home/travis/build/ArkNX/PSS_ASIO/PSS_ASIO/sonar-cfamily-reproducer.zip

Travis log:
https://travis-ci.com/github/ArkNX/PSS_ASIO/builds/221004835

[freeeyes]

@TomVanBraband thinks，I solved this problem.

The solution is as follows：
add CMake macro,

add_definitions(-DASIO_DISABLE_NOEXCEPT)

The reason for the crash is:

com.sonar.cpp.analyzer.Analyzer$AnalyzerException: Exit code != 0

Hello @kr.st.je, Thank to the reproducer you provided us, I’ve been able to reproduce the issue on my side. This is a know issue (see CPP-2696) related to the fact we are using clang to analyze the code, and clang does not play well with boost on Windows. You can see in one of the boost headers: template <typename Executor> friend BOOST_ASIO_CONSTEXPR blocking_t query( const Executor& ex, convertible_from_blocking_t, typename enable_if< can_query<const Executor&, possib…

[TomVanBraband]

@freeeyes Thanks a lot for sharing your solutions!