Pull request analysis shows zero lines

Hi all,
Setup:

  • Obj-C project
  • SonarQube Data Center Edition Version 7.9.2
  • SonarScanner 4.4.0.2170

I’m trying to perform pull request analysis to show results only on changed files. SonarQube seems to detect changed files correctly. I am able to locate the file in Measures->Coverage, but for some reason indicates zero lines. Also Overview page shows dash, instead of percentage for coverage (this forced quality gate to always pass no matter what). Among other required parameters like login, projectKey, etc I pass pullrequest.key, pullrequest.branch, pullrequest.base that use specific for this kind of analysis according to documentation. I’m not sure if I’m missing some runtime parameter or something else.

Hi,

What actually changed in the files of interest?

 
Ann

Hi Ann,

The file TestTriggerer.m was simply added, it is not present in the base branch (develop). I assume this testMethod should be considered as new code.

Hi,

There are possibly a couple things going on here. First, does the file fall under sonar.sources (i.e. is it considered “code”) or under sonar.tests (i.e. not “code”).

Second, either way, I would expect to see all the lines in the file colored yellow since it was added in the PR. But from the marginal markers, I can see that there are at least two, maybe three different commits in the file. That makes me wonder how old those commits are and whether they’re older than the PR’s branch / how the file was added to the PR. I.e. was the file added to the project (newly created), or is it an older file added to analysis via configuration changes such as an update to sonar.sources/sonar.tests or a change to exclusions.

Also, is this file the only one in question?

 
Ann

Hi Ann,

I couldn’t make this PR feature work for quite a while, so this is testing to troubleshoot the problem, thus, this is the only file in question and I expect Overview to show zero percent coverage, as there aren’t any test covering it. File falls under sonar.sources and is newly created in the PR’s branch.

What I find particularly weird is that sonar was able to identify code in file and even mark it as not being covered by tests, but still showing dash across coverage in Overview page.

Hi,

Sorry to be pedantic, but are the commit dates in the file before the creation of the PR’s branch? Detection of “new” works from the SCM dates.

 
Ann

It’s okay. First I created PR’s branch from base branch, then added new files, committed and pushed to the server. I assume this way commit dates are after the creation of PR’s branch, right? To be honest, I couldn’t think of the way to make commit dates of newly created file before the creation of the branch.

I see that you have 2 warnings from the last analysis. Did you check what they are?

Hi,

Yes, one is about PR decoration that did not happen (because I didn’t pass scm provider) and the other is something about cache use - “SonarCFamily plugin supports incremental analysis with the use of a cache…”.

With the latter I just passed -Dsonar.cfamily.cache.enabled=false option as the warning suggested, and warning went away. Still have dash across coverage.

What coverage information do you expect to see? What coverage reports are you trying to import?

I expect to see zero percent in the overview page instead of dash. From my perspective it correctly identified uncovered by tests lanes (second screenshot), but just doesn’t transfer this info to overview page. I’m trying to understand the why and if I’m missing something. Coverage report was generated by swiftlint in llvm format and passed to sonar via sonar.cfamily.llvm-cov.reportPath parameter

The first step to start troubleshooting is to enable the debug logs in the scanner. It should show whether the coverage report is being loaded by the scanner.

I found lines referring to llvm-cov report parsing,

Sensor llvm-cov [cpp]
Parsing .../reports/report.llcov
Sensor llvm-cov [cpp] (done)

and while in DEBUG mode lines stating about metadata generation for source files

'filename' generated metadata with charset 'UTF-8'

Is there anything else I should look for?

One thing you can check is whether the file paths in the report match the files indexed by the scanner.