-
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
-
-
- Open
-
- relates to
-
JENKINS-61392 Use information from SCM forensics to improve detection of new warnings
-
- Resolved
-
[JENKINS-61383] Current new messages detection mechanism is not working for simple line insertion in case of many similar adjacent warning
| Environment |
Original:
Jenkins 2.204.5 warning-ng 8.1.0 |
New:
Jenkins 2.204.5 warning-ng 8.1.0 Git Forensics 0.7.0 |
not sure I understand the question. The file is changed from time to time, I can run raw git command on this commit and report the result to help track the issue. I run the git blame both on build system and on the jenkins slave that runs the cppcheck and got the same results therefore I tend to think it is a problem in the plugin and not in our setup.
It seems that there is a problem in the way the plugin calculate the age for different lines. Moreover when I did rebuilt for the same job again - i got different lines that were reported with age 1 and therefore are reported new, which is another indication of a problem.
I see. Then a warning has been marked as new due to a refactoring, am I right? But the warning actually was not new...
AFAIU The warning has been marked as new due to the fact that the line age was reported (incorrectly) as 1 by the git forensics module.
This is not possible, detection of new warnings is based on comparing the warning sets of the current and the reference build. Are there some unrelated source code changes in sim_mgr.c (9264 +-5 lines) in the current build with respect to the reference?
i think that some lines were added. I will check again tomorrow.
all the adjacent lines had the same warning and some lines were added so the warnings shifted while some of the message were still valid for the new line.
regardless of the new mechanism. How come git forensics report different age for the same commit id?
The age has nothing to do with the Git blames. It is only computed from the properties of the warning. Two warnings are considered the same if they are equal with respect to all properties, or if the source code context is the same. The context is currently computed by the +-5 lines of the warning line.
The Git blame is computed afterwards: for every warning file and line git blame will be called. Seems that Git blame still can map the moved line of the old position.
Did someone change the file sim_mgr.c?