Duplicate fingerprints in checkstyle reports

[vincent-hennig]

Hi - Thanks for making this plugin!
When I tested it on a project, I noticed that Gitlab was showing fewer findings than were actually in the checkstyle report. I believe the reason is that the code quality plugin was generating many duplicate fingerprints which Gitlab is expecting to be unique.
Looking at the CheckstyleFindingsProvider, i believe that this happens when two findings share the same file path, severity, message text and column index which seems to be more common than one would expect. In my case it happened 17 times within one small project, leading to 17 unreported findings on the Gitlab UI.

Thanks again and let me know if you need any further information!

[chkal]

Hi @vincent-hennig. Sorry for the delayed response.

Yes, I guess you could be correct. GitLab is expected unique fingerprints but unfortunately Checkstyle doesn't provide such fingerprints by default (Findbugs does by the way). Therefore, I was forced to create fingerprints by myself as part of the plugin. Unfortunately this isn't easy to do. I ended up using the implementation you mentioned above which doesn't take the row number into account. I guess this is the reason for the issues you are running into.

The big question is: Do you have any better idea for creating such fingerprints that doesn't suffer from this issue? I would be happy to hear your thoughts.

Christian

[vincent-hennig]

Hey @chkal
It depends a bit on the requirements for these fingerprints. If they have to be identical across multiple pipeline runs then that makes it more difficult. Otherwise a UUID should be enough to solve the issue.

[chkal]

@vincent-hennig The need to be identical between pipeline runs. AFAIK GitLab uses these fingerprints to determine if a findings is new, was fixed or is still there. So if a fingerprint was not present in the previous run but shows up in the current run, this is a "new finding". If it was present in the previous run but not in the current anymore, that is a "fixed finding", etc.

[UlrichEckhardt]

Hi!

I'm not an expert on the matter either, but I think a good approach is to just extract the line where the warning originates and checksum that. It has the effect that any change to the surrounding code is ignored, in particular when a line is inserted or deleted before the line causing the warning.

An additional improvement on that would be to strip leading and trailing whitespace. That way, even when it gets indented differently (like moved into or out of a {..} block), it retains the checksum.

I'm unsure how much info SpotBugs and Checkstyle actually provide, but if they give the actual expression, possibly across multiple lines, you might improve the precision even further, but I don't have any experience in that area either.

BTW:

• Great plugin! I recently added it to two Java projects and managed to get it to run from your instructions without actually understanding much about the Maven ecosystem and it identified a bunch of issues!
• My biggest gripe was that it requires an additional step for multi-module projects. Would it be possible to automatically merge the data from the subprojects? I implemented a second job for that, because installing jq was not an option.
• Why is this not on gitlab.com? ;)

Cheers!

Uli