-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Jenkins 2.204.5
warning-ng 8.1.0
Git Forensics 0.7.0
Summary
1) Warning-ng marks messages as new although they are outstanding in some cases.
2) When it happens more then once it also might mess the age information.
It seems that adding git forensics might help to improve the detection algorithm. Some thoughts about what can be done will be added as a comment.
The problem
As you can see the message at line 9264 was marked as new therefore it's age was reset to 1.
but all lines were committed at the same time (only part of the line is shown) and were not changed in the last years.
Moreover every build that the detection fails gets new referenceId for that message and as a result the Age of the warning is reset to 1.
As a result after some builds with changes on other lines the age of lines that were committed together might be totally messed up as can be seen below.
you can see that for the same commit we get different ages.
The reason is that those messages were identified (incorrectly) as new along the time and their age was reset to 1 at the time.
see the 502_diff.xlsx attachment for more details
- is blocked by
-
JENKINS-6675 Invalid number of new warnings detected
-
- Open
-
- relates to
-
JENKINS-61392 Use information from SCM forensics to improve detection of new warnings
-
- Resolved
-
Well, some more info.
We tried an alternative algorithm.
All we do is we do diff for each reference file of sorted (by lines) warning to current warning file
1) The source_file_name, error id, error message, and the source line contents (NOT the line number).
This simple algorithm is giving quite excellent results for our case (currently as POC).
The only 'flaws' that we found
1) Someone changed the source code line but did not resolved the issue
2) Reordering content the source file without real change might cause real noise.
New idea:
The case that the line was changed but the problem exists although acceptable by users is still interesting to be identified for data mining.
It seems that we would like to add another category to the [new, resolved, outstanding]: touched.
So resolved means that the problem really solved and touched means that the line was changed therefore the full comparison fails but since the same error type still being reported for the line we will tag it as touched.
So in the case of changed line instead of getting 2 messages: resolved + new. We will get only one : touched
We still did not implement it, but soon will.
What do you think?