Thank-you for your answers.
No changes to the rules within the profile nor a change of the profile have been made since then. We tend to do annual Profile reviews where we clone the profile, make changes together with teams, then switch to the new profile and then lock them down so they can’t be changed. This approach has been taken since as far back as 2014.
We have done some more digging here and pulled up a few things.
- A case where a statement (legally) spread over 2 lines was combined and then a previous Issue found 4 years ago was flagged as new 8 days ago.
Is it normal for this to raise a new issue in this case? Is this because the hash of the statement taken only covers the first line so the old issue is then autoclosed and reopened because of this line change?
- The filter for closed issues on this project shows 0. The project has a history that goes back to March 2018 with hundreds of changes and is regularly analysed, however there are no Closed issues showing. Other projects do show Closed Issues
- We do observe this behaviour most following merges from feature branches into the Develop Branch probably because a lot of changes are happening at once. In this example below, the feature branch has altered the Catch block in a file with code changes to improve the logging within but, following the merge, suddenly the issue about not using a specific exception type is raised again even though that line has not changed.
Original code (as seen in the frozen Master Project analysis):
But after merge into the Develop branch of the change to the exception block from a feature branch, the issue was opened as new.
Is this because an exception block is treated as part of the same Exception Statement, so too many changes to the block will close all issues on the block AND the exception statement, and then create new issues again with what is found?
- In the next example a rule that has been present since 2015 is suddenly triggered on code in the newly analysed feature branch (analysed with 8.2) whereas in the earlier analysis (7.9.1) this was not raised. I should note that the function this was within was refactored to two functions but little else was changed. What is the reason for this?
Even if this appearing due to an upgraded plugin between these two versions (and that may not be the reason), should this not be backdated in any case?.
It seems to appear on Java code only and not be isolated to particular plugins or rules
I note this link where the intermittent availability of bytecode appears to produce similar symptoms. The build system is maven and analysis is only attempted after build and test/coverage steps.
Teams are required not to introduce new issues in branches and their performance reporting is based on this. This means they are quite sensitive to this behaviour so are very keen to find explanations.
Thanks again for your help.