SonarQube intermittently reopens issues

[swethap...@gmail.com]

Hi,

SonarQube intermittently reopens issues that have been closed off by team members.  

Sometimes a team member will need to close an issue as 'Won't fix' for a variety of reasons.  On occasion, the SonarQube server reopens these issues, sometimes months after they've been first closed.

Why does this happen and how can this be fixed?

Thanks,

Swetha

[Julien HENRY]

Hi Swetha,

Can you give an example of such issue and especially the rule key?

Also, can you look for the closed issue, and look at it's changelog, just to be sure it was closed in the same analysis (compare with the changelog of the new issue):

Regards,

Julien

[swethap...@gmail.com]

Hi,

Thanks for the suggestion.I have checked the cahngelog.

I got a doubt. Is there any possiblity that issues intermittently reappear when we submit totally unrealated patch sets??

Thanks,

Swetha

[Julien HENRY]

Hi Swetha,

What do you mean by "submit totally unrealated patch sets"?

If you do an analysis where one of the file previously analyzed is missing (because you analyze a different branch, or you change sonar.exclusions, or for any other reason) SonarQube will consider the file as removed, and close all associated issues. Then if you analyze again with the same file restored, SonarQube will consider the file as new (it will only compare to previous analysis), and all reported issues will be considered as "new".

++

Julien

[swethap...@gmail.com]

Hi Henry,

Thanks for the response. I have checked on your suggestion but the scenario is like below:

user1:- submitted his patch set and closed issues related to his patch
user2:- submitted his patch set and its re-opend user1 patch set issues which were closed by user1

These 2 patch sets were different and  not even concerning the same files . But still re-opened the issues closed

Could you please suggest what is going fault here.

Thanks,

Swetha

[Julien HENRY]

Le mercredi 13 septembre 2017 11:27:25 UTC+2, swethap...@gmail.com a écrit :

user1:- submitted his patch set and closed issues related to his patch

What do you mean by "user closed issues related to his patch"? Do you mean the user really fixed the issues by changing the code (and then submitted a new patch set, that was analyzed by SonarQube)? Or are you talking about using the action "Resolve as Fixed" in SonarQube UI?

[swethap...@gmail.com]

Hi Henry,

Some issues were fixed in the code and some issues were closed using "Resolve as fixed" in SonarQube UI.

Some time later (hours, days or weeks) somebody else pushes code for analysis & the issues earlier resolved as "won't fix" etc show up again and failed the analysis.

Thanks,

Swetha

[swethap...@gmail.com]

Hi,

Is there any peossibility that below scenario leads to re-opening the issues in SonarQube.

Please suggest me what is the reason behind this issue??

Thanks,

Swetha

[Lars Lykke]

Hi Julien

I'm observing a similar behavior, as described by Swetha, with our instance of SonarQube (v. 5.6.6 LTS), where issues marked as Resolved (Won't Fix) reappear as new issues.

I'm curious to learn more about when SonarQube regards a file as new vs. previously analyzed.

We're using TFS 2017 update 2 (on-premise) and TFVC for versioning and the corresponding plugin for SCM info.

What we're experiencing is that issues seem to have their changelog reset between builds (i.e. there is no history in the changelog). Hence, if a user has marked an issue as resolved (Won't fix) it reappears after the next analysis.

For other reasons, we've always cleaned the workspace on our on-premise build machines, which means that all files are downloaded from source control on each consecutive build. The analysis might also be executed on different agents depending on where ressources are available.

Could you please elaborate what could lead to this behavior of issues having their changelog reset on subsequent builds? Are we missing some kind of configuration in our setup?

Will SonarQube regard files as new, if workspace is deleted and files are downloaded from source control on every build?

I've also tried to describe this issue in a stackoverflow post, from which I was suggested to go to the mailing list for help.

Thank you for your help

/Lars

[pga...@gmail.com]

Hi Julien,

Any update on this?

We are observing exactly the same issue as Lars (TFS 2017 on prem, clean workspace etc. and issues marked as false positive reappear as new).

Pawel

[asj44...@gmail.com]

Hi,

We've also been encountering this problem under similar circumstances - TFS 2017 Update 2, TFVC, SonarQube v6.7 (and earlier), using the SonarQube build extension for TFS (currently v4.1.1). We have a number of build agents in the same queue, spread across multiple build servers, and the builds are set to clean sources as well. All our solutions are built for Visual Studio 2017 (MSBuild 15).

It looks to me as though on some builds some or all of the projects in the solution are just not getting their files analysed, so the analysis process updates SonarQube as though those files no longer exist and closes all the issues on those files. A subsequent run then recreates the issues, but obviously they don't have any of the manual changes we might have made ("Won't Fix", etc.). Looking at the issues in SonarQube it's possible to see all the closed issues with their history, so for us it's not just that the same issues are losing their status; they are being closed and new issues created as though it's a new file. I don't know if this is the same for other people who have encountered this?

It's not always all the projects in the solution, and it's not happening all the time. The Activity graph from the project pages shows where it has happened (all of these dips are where some or all of the issues have been lost, rather than developer changes, and sometimes it affects more files than others):

Comparing the analysis logs from two different runs, the only difference in the output where a project lost all its issues is that there is an extra line in the log for that project:  "2018-03-29T09:01:33.2400332Z INFO: 0/0 source files have been analyzed." There were the same number of files indexed each time and nothing else to indicate why they weren't analysed.

Is there any way we could get more detailed information from the analysis that might provide more detail as to why the files weren't analysed?

Thanks,

Andrew