- I am using SonarQube 6.7.2 community edition
- I want to break builds if the code coverage on new code (effective Jan 01 , 2019) is below 80%
- In order to do that i have created a quality gate with “Coverage on New Code” and “xxxx on New Code” + in admin setting modified the leak period to 2019-01-01 , after doing that i was expecting build to break since the code coverage is 0% … but its not ( i tried to run the pipeline within minutes of modifying leak period )
How can i achieve this ?
Hi,
First, did your project fail it’s quality gate with that analysis? If so, you’ve got most of the parts in place already. I think this is what you’re missing.
Ann
No my build didnt fail , i ran it immediately after changing date … also ran it after 2 days … .not sure how to correct this
Hi,
I wasn’t asking about your build. You’ve already been clear about that. 
I was asking about your project in SonarQube. I.E. Do you see ‘Passed’ or ‘Failed’ here:
Ann
thanks for clarification … its showing Passed
Hi,
Then your first task is to figure out why your project is passing your quality gate when you expect it to be failing. Even if you have all the pieces in place to break the build for a failing quality gate, it’s still not going to break anything if the project passes the quality gate.
Ann
Right, let me share my point of view
- the configure quality gate is
- why its passing … not sure i guess thats why i opened this thread … i think i have all pieces in place to break build a) definition of date (leak period) b) defined code quality gate but it still passes … it should fail because i have 0 code coverage and as per Quality gate expected code coverage for code since 01 Jan is 80%
i guess a better question is … how can leak period be configured for date in past ? and how can we expect the QualityGate work for “xxx for new code”
Hi,
How about a screenshot of your project homepage?
Ann
Hi,
All your Quality Gate criteria are about New Code - the stuff in the yellow section on the right. So it doesn’t matter what your overall coverage number (what you’ve got circled) is.
Your screenshot reports “-” for coverage on new code. That seems functionally equivalent to 0, but isn’t quite the same for these purposes. I’m guessing you have 0 “coverable” lines changed in the New Code period. Your Measures page will give you that number. Here’s what it shows for a project with a “-” for new code coverage on our internal instance:
Ann
Thanks for your pointers , it helps.
I checked my measures page. i dont see “On new code” section … not sure why ? am i missing something in sonar.properties file ?
- sonar.host.url=http://sonarqube-url:9000*
- sonar.projectKey=MYUI*
- sonar.projectName=MY-UI*
- sonar.projectVersion=1.0*
- sonar.language=ts*
- sonar.sources=.*
- sonar.tests=src*
- sonar.test.inclusions=/tests/*
- sonar.coverage.exclusions=/tests/*
- sonar.exclusions=dist/, node_modules/*, src/lib//.test.ts, playground/, src/lib//.service.ts, src/lib/module.ts, src/setup-jest.ts, src/index.ts*
- sonar.typescript.lcov.reportPaths=coverage/lcov.info*
- sonar.scm.disabled=false*
Hi,
Try expanding the “Coverage” section (as included in my most recent screenshot).
Ann
thanks
I checked the coverage section , its same as you shown in your image.
But i have added a lot of code in my GIT repo since 01 Jan 2019 ( leak period ) I understand GIT date is not taken as input to sonar … but there has been many sonar scans since 01 Jan 2019… why is the coverage section showing 0 ?? ( note i have added code in different feature branches and using sonar community edition )
-
how does leak period (date) play a role in code quality gate “xxx for new code”?
-
How is leak period (date) related to GIT checkin date ?
-
How will this (leak period date) behave if i use sonar community edition instead of dev edition ( i am modifying different branches in my GIT repo … but sonar always thinks its master )
our use case is given a date ( lets say 01 Jan 2019 ) all code in our organization should follow the new code quality gate … how can we achieve this ?
Hi,
You’ve asked a lot of questions
If you’re seeing 
then coverage on new code shows up as “-” on the homepage because there’s nothing to measure. I.e. of all those lines you’ve added since Jan. 1, none of them is recognized as “code”.
If you’ve set your new code period (Administration > General Settings > New Code Period) to a date in a yyyy-MM-dd format, then lines changed in analyses after that date are considered “new”.
For consideration of new lines and coverage, the two are unrelated. At the risk of muddying the waters, issues are sometimes backdated to the Git commit date, but lines never are. And Coverage on new code is based on which lines are “new”.
Exactly the same
That’s an entirely different topic. Let’s not get into that in this thread unless we absolutely have to.
- Set your New Code Period to your cutoff date
- Set your Quality Gate to evaluate New Code
- Analyze on a regular basis
For the next round on this, how about a screenshot from SonarQube of a new line that you think should be marked uncovered but is not.
Here’s an excerpt of our Projects page in the New Code perspective with a project with “-” coverage on new code and 394 new lines
If I drill into this project I see that the new lines are not lines of code, and therefore not coverable:
So for your project where the dashboard shows “-” coverage on new code, please take a look at the New Lines (you can use the link in the duplications card to jump straight to it) and examine the new lines to see if you can find one that is actually a line of code.
Ann
thanks for your patience in answering all of my questions
i can share after adding some code
But just curious ( coming back to original question ) … (1) can the leak period (date) be a date in past ? (2) if yes then why are new lines added not recognized as new code ? ( we have added major functionality in our angular project )
I am following all the three steps suggested by you
- Set your New Code Period to your cutoff date
- Set your Quality Gate to evaluate New Code
- Analyze on a regular basis
Hi,
If It’s going to be a date, I believe it can only be a date in the past. And from what I gather, you’ve already verified empirically that it can be a date in the past
Good question. They should be. Can you show me where they’re not? Also, you’re not using the sonar.projectDate parameter in analysis, are you? I’ve just noticed this odd detail in your project homepage screenshot and I’m not sure how to explain it otherwise:
Ann
Let me get back to you on that
in mean time if you notice on my GIT commit history (i posted ) i happen to change the sonar key off late … i guess that also limits my history to the “new key date i.e. 22 May” rather than “01 Jan 2019”
Yes, when you change the project key you create a new project. So everything changed after your first analysis is eligible to be considered new code.