Hmm, strange. The different properties look fine. Severity and package is a reference just to save memory. Reference is the reference build which is not used in equals, id as well. Do you still have a result file of one of the builds before the upgrade? Maybe some properties are different.

What makes me wonder: all issues have a fall back fingerprint: <fingerprint>FALLBACK-2e4a982f</fingerprint>. Did the warnings plugin report errors that it cannot read your source files now?

I attached the xml from the last build before updating the plugin. I can't see any differences.

For fingerprint  problem there are some lines in the logs:
[DelphiXE] [-ERROR-] Can't create fingerprints for some files:
[DelphiXE] [-ERROR-] - '...', provided encoding 'UTF-8' seems to be wrong
...
[DelphiXE] [-ERROR-] ... skipped logging of 1273 additional errors ...
But this error already existed before the update. It seems to be, because we are actually switching from windows encoding to utf-8.

namuecyd for me it is interesting to see that you have the warnings-ng problems with delphi compiler output. We're using delphi too and just ran into the same problem. I wonder if it has something to do with the compiler output itself. I wrote a tool for our internal use that post-processes the dcc32 output and normalizes paths, so that there are either no relative or no absolute paths left in the output.

This is totatlly crazy:

One of the first failing builds
Build 51: (+352 new FixInsight warnings, 633 total)

Reset Quality gates -> next build
Build 52; (633 total Fixinsight warnings)

Build 53; (+352 new FixInsight warnings, 633 total) What?!?

Note that the open task scanner never fails, even though it should come across quite a few duplicates as well.
The Delphi compiler and FixInsight parsers are both Groovy based, in case this helps to localize the issue.

The plugin was updated between builds 46 and 47. The graphs on the overview page look like this:

Our project is a pipeline project. Our pipeline script replaces absolute paths by relative paths where possible und writes the output into logfiles.
But if there is something wrong with the delphi output, or with our parsing, the error should be visible in the xmls I provided here.

Ok, I think I found the root cause for the problem: the new warning detection currently does not work if there are issues in a report of reports that are the same (with respect to equals). In version 9.x those issues have been counted as duplicate and were not added so this was no problem before. But now they are added if they are part of a different sub report.

There are two ways to fix it: restore the old behavior and remove all duplicate issues, even if they are part of different sub-reports. Or I can try to make the delta computation aware of hierarchical reports.
I wonder what you would like to see in your use case? When you are scanning n files that all contain the same warning, should there be just one warning or n of them?

In our logic it is one error, that has to be fixed one time. So it doesn't need to be there multiple times.

I'm late to the party, but: "same here".
The warning is caused by one file which is included several times via different build configurations, so it has to be fixed only once.

I released a fix in 10.2.1. but since this fix breaks another thing I‘m not sure if I need to revert that PR. Changing a report after it has been created is not a good idea...