Old issues closed and reopened as new ones


We have a question regarding the management of issues in Sonar: recently Sonar has closed a bunch of old issues, and on the next analysis reopened them all again.
Consequently the issues appear now as new ones, and as such qualify no longer as “old code”, which makes the Sonar analysis fail on the Quality Gate.

We are using Bamboo as our CI tool, and the projects are configured to run Sonar analysis as the last step of build process.
We are using jacoco-maven-plugin of version 0.7.9 to run the analysis, and the result of this analysis are sent further to the Sonar server for subsequent processing.

What happened is that at some point the build, which was waiting for the Sonar server response, was killed manually.
Once the bamboo build was stopped, Sonar passed all the old issues for this project to Fixed.

Here are the chronology of what has happened:

  • 2 years ago a first Sonar analysis was run on a project and vulnerability issues were discoverd in the code.
    these issues were living there as old code issues, thus not impacting the Quality Gate

  • few days ago a project build has been started as usual on Bamboo

  • the build has advanced as expected through all the phases (compile and test), and finally started the Sonar analysis

  • the analysis has been terminated successfully and a report has been sent to the server for subsequent processing

  • when the build was in the phase “Waiting for report processing to complete…”, it has been killed manually by a user (at 11h40)

  • at this point on the Sonar server side all the old existing issues were passed to “Fixed”

  • when the next analysis was run, Sonar has discoverd these issues once again, and reopened them all, but this time with the status “new code”, as apparently

From the screenshots we can see that the old issues were passed a Fixed precisely at the moment when the Bamboo build was killed (11h30 ~ 11h40)

So we would be very thankful if you could clarify the following questions:

  • is there a way to make Sonar analysis more “Bamboo kill resistant”? i.e. what should be done to prevent the Sonar state of the project to be impacted by the Bamboo build improperly finished?

  • is there a way to reunite the old and new issues again, or mark new issues as “old code”, so that they won’t break the Quality Gate?

As a workaround for now we had to mark all the new issues as “Resolved - Won’t Fix” to fix the Quality Gate problem.

According to this old thread we might suspect that the bytecode from the project was missing on the Sonar side.

Any help would be highly appreciated in this regard.


Hi Emzar,

It sounds like your Background task processing was cancelled by BitBucket when the job was killed. Ordinarily, killing your CI job should not stop background task processing, so this looks like some extra-step integration on the BB side. Maybe you can toggle it off in the BB settings? It’s certainly worth investigating. And if not, I would take it up with the maintainers of that integration.

Regarding your issues… there are a lot of cases were issues are backdated automatically, but unfortunately your situation is not one of them. However, some work was done in the 7-series to automatically re-open issues in this kind of case.

I was about to suggest you upgrade to 7.9.1, the latest version and current LTS, analyze with an empty profile to close all the issues, then re-analyze with the normal profile to have SonarQube re-open the closed issues. But at this point you have 2 copies of each issue and it’s not clear which one would be re-opened. Murphy’s law says the new one.

So I think you’re left with the not-great option that was the first thing I thought of: either delete or re-key the project (to set it aside) and re-analyze. It will be the first analysis of a “new” project and issues will be backdated automatically. The obvious downside of this is that you’ll lose your project history and all the manual issue status changes (False Positive, Won’t Fix) you’ve made. It will also mess with your leak period since that first analysis will be the earliest baseline you can have.

A twist on that scenario is that you check out the version of your code that should start your New Code Period and use the sonar.projectDate parameter to backdate the entire analysis. Then you can check out the current state of the code, drop the extra parameter and kind be back to normal (minus, of course, history &etc).


Ok, thanks for your reply,
We’ll look into it