Code coverage on branches does not break quality gate

Opened separate thread for coverage report -
https://community.sonarsource.com/t/unable-to-import-view-pytest-code-coverage-in-sonarqube-version-7-7-build-23042-when-sonar-scanner-is-executed-from-jenkins-pipeline/9803/2

2 Likes

Hi @LucaIpp

Did you end up figuring out if and why there was no SCM data in your analysis?
You mentioned trying mvn clean install sonar:sonar -Dsonar.branch.name=testBranch -Dsonar.branch.target=master. Did both testBranch and master exist in the local clone being analyzied?
If you still have a problem, could you please post the logs with debug enabled?

Hi @dmeneses

I’ve worked with an evaluation license when I discovered the problem. This license is not valid anymore and our test system isn’t available anymore since it was not maintained by our own team and is used differentyl now.
We decided to order a license now, because we basically know that SonarQube will fulfill our requirements and the problem we faced is actually getting worked on. But it will take a while until I receive the license because of bureaucracy. I am also off for the next two weeks, so unfortunatly I assume that I am not able to provide your requested data currently.

Regarding your question:
Since our testsystem’s data was basically copied from our Community Edition SonarQube instance, it is possible that I’ve never built the master branch locally with mvn clean install sonar:sonar since data of it was available on our testsystem. Both branches did definitively exist, but I probably only bulit the test branch with mvn clean install sonar:sonar -Dsonar.branch.name=testBranch -Dsonar.branch.target=master.

Ok, thanks!

Hi

It has been some time since I last updated this issue because I was off for a few weeks.
Our current situation looks like this now:

  1. We bought a license for SonarQube Developer Edition
  2. I tested the branch analysis with our jenkins build queue, the issue is also present

My current questions are:

  1. The Issue mentioned by @ganncamp ([SONAR-11996] - Jira) has been fixed in the meantime, which should fix the issue I am having. The fix is planned for release 7.8, when can we expect this to get rolled out?
  2. About the comment of @dmeneses:

Can you explain how this workaround needs to be configured? How can I load the needed SCM data so the analysis works properly?

Hi Luca,
SONAR-11996 is a fallback strategy, only used when SCM data is not found by the Scanner for the branch being analyzed and its target. If Jenkins is cloning the project (note that this should not be a shallow clone or a clone of a single branch), the SCM data should be available without further action. Using the SCM data is always preferable over the fallback mechanism as it guarantees that SonarQube will display the same code as “new” as seen in the SCM.
If you still get 0 “new lines”, could you please post the logs of the scanner with debug enabled?

Hi Duarte

Thanks for your feedback, now I am getting what the issue seems to be. Good news: Localy I was able to make it work.
When building with jenkins, I am getting this warning:
[2019-06-19T08:35:49.347Z] [WARNING] Could not find ref: master in refs/heads or refs/remotes/origin
Also, I see this message in SonarQube:
image
So I think this is what you are talking about, right?
I will get a look at our jenkins pipeline to find out how to fix this.

Yes, that’s it. Looks like Jenkins is cloning only the branch that is built (maybe with --single-branch).

Hello Luca
Which Branch Sources are you using in Jenkins? I’ve found out, that the “Bitbucket”-Source does the git fetch wrongly (something with restricted refs fetching, like +refs/heads/feature/).
The Source “Git” does it correctly with +refs/heads/:refs/remotes/origin/

I have same problem. I opened an issue on the BitBucket Branch Source Plugin GitHub site.

I solved the problem by adding the git behavior “Specify ref specs” with the value "+refs/heads/ :refs/remotes/@{remote}/ ".
Now the sonarqube branch analysis works correct.