I’m looking for clarification on when “Some Quality Gate conditions on New Code were ignored because of the small number of New Lines” is expected to appear?
We are nearing a release and therefore are at the end of a leak period which is a couple of months long. Recently someone changed (reformatted) 3 lines of code in a project that hasn’t been touched the entire release. Those 3 lines of code got flagged by our quality gate because they didn’t have any unit tests.
However, these were not new lines of code, exactly. They were just old lines, reformatted. Additionally, they were reformatted by a developer who did not write the original code. Although the desired action is for him to write new unit tests, I’m curious as to why the “Some Quality Gate conditions on New Code were ignored because of the small number of New Lines” did not appear given that only 3 lines were changed for this project?
Is this supposed to be on a per-project basis? Or is it supposed to encompass all the projects and be on a per-release basis? Or does it only appear at the beginning of a leak period? I’d like to understand this better.
Currently at least in the LTS this includes all new lines, not coverable lines of code (e.g you can make maven pom changes and easily go over the hardcoded 20 line limit). I beleive there was already a bug or feature request for this somewhere as I remember reading it.
There are indeed a few relevant past discussions (and related tickets) on this topic. I’ll share those and let you follow-up if any remaining question:
initial implementation @ SONAR-9352 (Quality gate should not fail when too few new lines of code)
Thanks for your replies and links.
So if I understand correctly, the message will appear only in the beginning of a leak period, and across all projects (rather than on a per-project basis) until 20 lines total are changed or created.
If that’s correct, I’d like to request a change:
I’d like the message to appear per project regardless of where it is in the release cycle.
As I described above, a developer reformatted 3 lines of code in a given project at the end of our release cycle. In a case like that, we’d like the conditions on new code to be ignored regardless of how late in the release cycle this happens.
Not sure where you understood it to be accross all projects, but surely I can confirm that this behaviour is per-project.
I wouldn’t see it specifically with respect to the beginning of the Leak Period. The special condition applies as long asNew Lines is below 20 (with a plan to track new_lines_to_cover instead in the future).
If we go back to what you described initially:
First, note that SonarQube does make a distinction between a new line and a modified line. In both cases it’s New Code.
Secondly you didn’t specify precisely which Quality Gate condition failed, that would help understand more precisely your situation. Last but not least, as per our discussion here, independently of the 3 lines changed there, what matters for the QG is also the overall amount of Lines modified/added since the beginning of the Leak Period.
Ultimately the [Deprecated] Suggest new features category is available to make proposals, however I feel here that your understanding/thoughts are worth double-checking to avoid any misunderstanding (I recommend you do a few tests on dummy code if any doubt remains).
Apologies for not clarifying: This particular quality gate fails if code coverage is less than a certain number in new code (since the beginning of the leak period).
At this point I’m only allowed to upload one screenshot per message, so in the screenshot attached here you see that 3 lines of code have been added to the project (named “cmc”). These are actually changed lines. With only 3 lines changed, I would have expected the “Some Quality Gate conditions on New Code were ignored because of the small number of New Lines” to appear, but it does not. You should be able to see that the quality gate is triggered and red in the screenshot of the following message. I’m wondering why is this happening given that only 3 lines have changed in this leak period, for this project?
Good point, and I should have caught that before. I just checked and we did have 33 lines changed in that project, which I think explains what I’ve been seeing.
I know you have SONAR-10231 open but still unassigned. Looks like a fix for that would really help us out. Any idea if/when that will be addressed? I did add a vote for this issue.
The fact that this is currently scheduled for 7.x-Series indicates that we’d like to get it done before the next LTS. I can’t give you any specifics beyond that.
