|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Hi Michal
It's been a difficult one to explain this one![]()
I understand that the data is dynamic. I have had to use this approach to force delta generation between the last stable build and the current build, by deleting all the intermediate builds. This issue I am having is that builds are churned out every ten minutes, which is faster than developers are able to fix the CPP check warnings that they have introduced. So what happens is, you get this intermediate build that sits between the last stable build and the current build. The current build shows no difference, so you can't use it to determine what new errors were introduced. You have to go back to the intermediate build to identify the errors.
But at the same time, the current most build shows what errors have been resolved since the last stable build. So they accumulate as errors are resolved across unstable builds. This is also odd, because what is interesting to me and my development team, is what warnings did we fix since the last unstable build? Also, how many errors are left from the warnings we introduced since the last stable build? Does this make sense?
So if build 1 is stable and I introduce 5 cpp check warnings in build 2 and someone else introduces 3 warnings in build 3 and another build comes out with no additional warnings (build 4), the delta is zero. If I delete build 3, the delta is 3, because it shows the warnings introduced between build 2 and 4. If I delete build 2, then I see what I would expect to have seen, that being the total number of errors since the last stable build (build 1). That said, without deleting any of the builds, if I fix one warning in build 5, it will continue to show 1 warning has been solved for all builds until the next stable build. I would expect it to show specifically the delta between the build that had the error and the build that resolved it, but nothing outside the scope of this.
I don't necessarily think there is anything wrong with the cppcheck report, it all comes down to how the plugin represents the results between builds. The simple solution for me, would be to swap the comparisons such that resolved errors are shown since the last build and new errors are since the last "stable" build, which is the inverse of what I am currently seeing. The more complicated solution would be to have this as a configurable set of options, allowing the job to define what builds are used to represent the deltas.
I hope this clarifies my issue and what I am asking for?![]()
If not, I will need to fork the plugin and make the changes and submit a pull request so I can demonstrate it to you.