|
||||||||
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.
I understand WHAT you want but I don't understand WHY you want it. Your usage patter is from the very special ones.
As I understand you have a set of issues reported by Cppcheck, let's say 100 of them, which you want to just ignore and never fix. So you set a threshold to make the build unstable if there is more than 100 issues. And you want to update the plugin to see all issues that don't belong to the 100 known ones in the latest build. You are also dropping the history off time to time so you are not sure which issues were the 100 original ones, but you know there were 100 of them. Correct?
My suggestion was to analyze that 100 issues and use --inline-suppr, --suppress or --suppressions-list cppcheck arguments to hide them. Cppcheck would report no issues instead of 100 now and any issue present in the latest build would be in "to fix" category. Does it make sense?
Questions:
Feel free to create a feature branch for this task and send a pull request.
That's just my two cents.