The Compilation Database JSON file was found but 0 C/C++/Objective-C files were analyzed

SonarQube Cloud
, ,
1

Hi Team,

I was not able to finish sonar scan for one of our GitHub repository with GitHub actions workflow it was throwing error with compilation database json file has not c/c++/obj-c files in it. I’m using Sonar-Cloud for C++ code static analysis of my open-source project https://github.com/usdot-fhwa-stol/carma-ns3-adapter. we are able to generate the reports for other repositories with same configurations. Here is the example repos we generate repos: Merge master branch into develop (#115) · usdot-fhwa-stol/carma-cohda-dsrc-driver@6a18511 · GitHub

Could you please help me with this issue, Thanks in advance!

Sonar Properties:

sonar.projectKey=usdot-fhwa-stol_CARMANS3Adapter
sonar.organization=usdot-fhwa-stol
sonar.host.url=https://sonarcloud.io
sonar.sources=ns3_adapter/src/
sonar.cfamily.gcov.reportsPath=/opt/carma/coverage_reports/gcov
sonar.coverageReportPaths=/opt/carma/coverage_reports/gcov/coverage.xml
sonar.cfamily.compile-commands=/opt/carma/build/compile_commands.json
sonar.cpp.file.suffixes=.cpp,.h,.tpp
sonar.c.file.suffixes=-
sonar.tests=ns3_adapter/test/
# Set Git as SCM sensor
sonar.scm.disabled=false
sonar.scm.enabled=true
sonar.scm.provider=git

GitHub actions workflow: carma-ns3-adapter/ci.yml at fix/sonar · usdot-fhwa-stol/carma-ns3-adapter · GitHub

Build logs:
NS3-ADPTOR LOGS.txt (2.5 MB)

2

Hi,

Welcome back!

Thanks for the logs. I guess I don’t know how to read this. Can you point out to me where the build-wrapper is invoked with the build command?

 
Ann

3

Hi Ann,

Thanks for the reply!

build and tests are running with following commands in our github actions workflow.

    - name: Build
      run: |
        source "$INIT_ENV"
        source "$ROS_2_ENV"
        sed -i '/colcon build/ s/$/ --packages-up-to ns3_adapter/' /home/carma/.ci-image/engineering_tools/code_coverage/make_with_coverage.bash
        make_with_coverage.bash -m -e /opt/carma/ -o ./coverage_reports/gcov
    - name: Run C++ Tests
      run: |
        source "$INIT_ENV"
        source "$ROS_2_ENV"
        sed -i '/colcon test/ s/$/ --packages-above ns3_adapter/' /home/carma/.ci-image/engineering_tools/code_coverage/make_with_coverage.bash
        make_with_coverage.bash -t -e /opt/carma/ -o ./coverage_reports/gcov

We are using the scripts from our base image : carma-base/code_coverage at develop · usdot-fhwa-stol/carma-base · GitHub

let me know if you need more info. Thank you!

4

Hi,

Sorry, but I’m still missing where build-wrapper comes into play…?

 
Ann

5

I think we are not using build wrapper compiler, we have replaced it by compilation database with adding CMAKE_EXPORT_COMPILE_COMMANDS argument in make_with_coverage.bash script (carma-base/make_with_coverage.bash at develop · usdot-fhwa-stol/carma-base · GitHub) correct me if I’m wrong

1 Like
6

Hi,

Sorry. You said that to start with. :woman_facepalming:.

So here’s what’s interesting about your log:

2023-05-31T20:05:24.6448576Z INFO: SCM collecting changed files in the branch
2023-05-31T20:05:24.9994963Z INFO: SCM collecting changed files in the branch (done) | time=354ms
2023-05-31T20:05:25.0967727Z INFO: Indexing files...
2023-05-31T20:05:25.0968149Z INFO: Project configuration:
2023-05-31T20:05:25.0977714Z INFO:   Excluded sources: **/build-wrapper-dump.json
2023-05-31T20:05:25.2449638Z INFO: 8 files indexed
2023-05-31T20:05:25.2457502Z INFO: 0 files ignored because of inclusion/exclusion patterns
2023-05-31T20:05:25.2461408Z INFO: 0 files ignored because of scm ignore settings

Analysis only finds 8 files of interest.
But it seems there are more than 8 files in the project:

2023-05-31T20:05:30.9245854Z INFO: Sensor gcov [cpp]
2023-05-31T20:05:30.9314104Z INFO: Parsing [coverage report for a single file?]
2023-05-31T20:05:30.9345164Z WARN: File not analysed by Sonar, so ignoring coverage: [the single file]

The Parsing... ignoring pattern happens 367 times, so there are apparently a lot more than 8 files in the project…?

Going back to the OP, I see that the source files are supposed to be in ns3_adapter/src/, but none of the paths reported for ignored files include that string. I suppose that’s why indexing only found 8 files. The question is whether this is expected on your side, and why you’ve submitted coverage reports for all those extraneous files.

Going back to the 8 files, it seems that most are unchanged:

2023-05-31T20:05:32.3380450Z INFO: Sensor CFamily [cpp]
2023-05-31T20:05:32.3947233Z INFO: CFamily plugin version: 6.45.0.62016
2023-05-31T20:05:32.3955620Z INFO: Using compile commands: /opt/carma/build/compile_commands.json
2023-05-31T20:05:32.3990434Z INFO: Available processors: 2
2023-05-31T20:05:32.4076140Z INFO: Using 2 threads for analysis.
2023-05-31T20:05:35.8130977Z INFO: Found empty cache on server
2023-05-31T20:05:36.3534895Z INFO: PCH: unique=0 use=0 (forceInclude=0,throughHeader=0,firstInclude=0) out of 0 (forceInclude=0,throughHeader=0)
2023-05-31T20:05:36.3538698Z INFO: Z3 refutation rate: 0 out of 0
2023-05-31T20:05:36.3538943Z INFO: SE: 0 out of 0
2023-05-31T20:05:36.3551827Z INFO: Subprocess(es) done in 542ms
2023-05-31T20:05:36.3593822Z INFO: 4/6 files marked as unchanged
2023-05-31T20:05:36.3603243Z INFO: 2/2 test files marked as unchanged

Back at the top of the log, we see that this is a short-lived branch analysis.

2023-05-31T20:05:24.1055613Z INFO: Branch name: fix/sonar, type: short-lived

I’ll be honest and say I’m a bit fuzzy on how short-lived branches are analyzed in SonarCloud. On the PR side, we only analyze changed files. I’m not sure whether short-lived branch analysis has been updated for that as well or not. But we certainly only report on changed files in short-lived branches.

So what that leaves us with is that at least 2 files that theoretically could have been reported on and were not.

I think now it’s time to ask: were you nodding along with all this^ or do we need to start with why only 8 files were indexed? And if you were nodding along, did you expect only changed files to be analyzed? And also, can you add sonar.verbose=true to your analysis properties & post the new log?

Tangentially, on the topic of your analysis properties:

  • sonar.scm.disabled=false - this is the default. no need to set it
  • sonar.scm.enabled=true - this isn’t a thing
  • sonar.scm.provider=git - if this isn’t picked up automatically, setting it explicitly won’t help

 
Ann

7

Thanks for the information! Ann

we made few changes and now the unit tests are failing before sonar step. I will update you one developers fixes them. Thanks!

1 Like
8

did you ever solve this issue ? i am experiencing the same issue .