SonarQube New Code and Reopened Issue

Report a bug
,
#1

Report description:

  • Version: SonarQube Community 7.9.6 (LTS)
  • Steps to reproduce
  1. Create a simple Hello World Java Project
  2. For this project, create a Quality Gate based on new code (critical and blocking issues greater than 0) and overall code (reopened issues greater than 0)
  3. Run the analysis on top of this project that has no critical/blocking issues (Result: Quality Gate Passed)
  4. Add a critical or blocker issue to the code, and rerun the analysis (Result: Quality Gate Failed)
  5. Remove the issue from the code, and rerun the analysis (Result: Quality Gate Passed)
  6. Add the issue back to the code, and rerun the analysis (Result: Quality Gate Passed)

In my understanding, in 6th step, the result of analysis should have been Quality Gate (QG) Failed instead of QG Passed.

My questions:

  1. Why didn’t SonarQube consider the code added in step 6, as new code? (since in step 5, that code did not exist)
  2. Why didn’t SonarQube consider the reopened issue to break the quality gate? See the issue history of this added code. Isn’t it a “reopened issue”?
    image
#2

Hi,

There are a couple things going on here.

First, I’m curious about your New Code Period definition. It’s not previous_analysis, is it?

Second, you’ve found what we truly consider a feature-not-a-bug. Here’s the scenario:

  1. Long-running project has new admin who wonders (as one example of many possible causes) “what these exclusion settings do” and does a little experiment to find out.
  2. All issues are closed at the next analysis.
  3. In a panic, the new admin resets his changes and re-runs analysis.
  4. All issues re-created as “New”.
  5. Developer riot ensues.

So when a recently* closed issue is re-raised (see Understanding which Issues are “New”) we… re-raise it, rather than creating a new issue. And yes, that includes re-instating the old dates (and update log!).

To be honest, I’ve never seen anyone complain about this behavior except in a we-were-testing-you-and-you-failed scenario such as yours.

 
HTH,
Ann

* Closed issues are cleaned out after 30 days.

#3

Hi G Ann, thanks for your replying.

I am using the default new code definition, that is “previous version”. But the same error occurs, for example, if I change it to a specific version analysis.

I’ve added the image below, for a better understanding of what I’m saying (in case there are still doubts) :

image
image976×408 19.7 KB

I’m pointing out this behavior, because in our pipeline, the quality gate status is important. And, with this behavior, we see that there`s a scenario where the quality gate can be ignored.

To ignore the Quality Gate, it would only be necessary to remove the code with that “bug”, run the analysis, put the code again and run the analysis.

And, last question, are there no metrics to identify those “reopened issues”?

Thank you for you assistance,
Christofer

#4

Hi,

First your new code period. My first reading of your illustration was that you were changing the version number with every build. On closer inspection, that’s not what you’re showing… but is that what you’re doing? Are you by any chance passing in a build number for sonar.projectVersion? Because with a New Code Period set to previous_version it would mean that you re-set the New Code Period with every analysis and get the behavior you describe. Given your complaint, I don’t think that’s what you want.

The idea is that you would change the value of sonar.projectVersion with every release to production. And that should be the behavior you’re after.

 
HTH,
Ann

#5

Hi Ann, thanks for your replying.

I believe that the image has given a incorrect understanding. So I did another one:

For the illustration, the commit timeline will be:
image

The scan results are:
image

The sonar.projectVersion contains the version of the project (1.0, 1.1…).

The “New Code Period” is set by “A version”. It gets updated everytime a pipeline runs the analysis and the project passes the quality gate.

In the illustration, code 1.0 has no issues (new code period: 1.0).
Code 1.1 adds a code with a critical/blocker issue (new code period still 1.0).
Code 1.2 removed the code (new code period: 1.2).
Code 1.3 adds the code previously removed, and QG passes.

QG is based on “New Code”

#6

Hi,

I’m going to refer you back to my March 18 answer & reiterate that this is about which issues are New.

In v1.1 the issue is created
In v1.2 the issue is closed
In v1.3 the issue is reopened not re-created. And it’s reopened with the original date, so it’s not “new”.

 
HTH,
Ann