[JIRA] [cppcheck] (JENKINS-24076) Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced)
Michal Turek commented on JENKINS-24076 Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced) Please see comments in your pull request, they should be solved before merge. https://github.com/jenkinsci/cppcheck-plugin/pull/24 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.
[JIRA] [cppcheck] (JENKINS-24076) Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced)
Craig Phillips commented on JENKINS-24076 Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced) I am looking at this issue and trying to build the plugin. I am seeing the following maven errors, can you help? WARNING The POM for org.apache.maven:maven-plugin-api:jar:3.0.3 is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details ... INFO maven-hpi-plugin:1.74:test-hpl (default-test-hpl) @ cppcheck INFO Generating /var/lib/jenkins/jobs/jenkinsci-cppcheck-plugin/workspace/target/test-classes/the.hpl INFO INFO BUILD FAILURE INFO INFO Total time: 5.706s INFO Finished at: Thu Sep 18 10:06:49 BST 2014 INFO Final Memory: 24M/347M INFO Waiting for Jenkins to finish collecting data ERROR Failed to execute goal org.jenkins-ci.tools:maven-hpi-plugin:1.74:test-hpl (default-test-hpl) on project cppcheck: Error preparing the manifest: Failed to open artifact org.apache.maven:maven-plugin-api:jar:3.0.3:test at /var/lib/jenkins/.m2/repository/org/apache/maven/maven-plugin-api/3.0.3/maven-plugin-api-3.0.3.jar: 1 problem was encountered while building the effective model ERROR FATAL Non-parseable POM /var/lib/jenkins/.m2/repository/org/apache/maven/maven-plugin-api/3.0.3/maven-plugin-api-3.0.3.pom: only whitespace content allowed before start tag and not 0 (position: START_DOCUMENT seen 0... @1:1) @ line 1, column 1 ERROR for project for project ERROR - Help 1 ERROR ERROR To see the full stack trace of the errors, re-run Maven with the -e switch. ERROR Re-run Maven using the -X switch to enable full debug logging. ERROR ERROR For more information about the errors and possible solutions, please read the following articles: ERROR Help 1 http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException 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.
[JIRA] [cppcheck] (JENKINS-24076) Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced)
Craig Phillips commented on JENKINS-24076 Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced) It's okay, I figured it out. I had previously run maven with the wrong settings file and it mis-configured its local repo. I removed the repo (/var/lib/jenkins/.m2/repository) and repeated the build and it worked fine. 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.
[JIRA] [cppcheck] (JENKINS-24076) Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced)
Craig Phillips commented on JENKINS-24076 Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced) I have noticed another "bug" recently. If you set the maximum new error threshold to 1 and you have a build where one new error is added, but at the same time, one is resolve, the delta is zero but the build is flagged as stable. This doesn't seem right. 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.
[JIRA] [cppcheck] (JENKINS-24076) Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced)
Craig Phillips commented on JENKINS-24076 Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced) My previous comment with regards to the bug. This is actually a side effect of the fact the plugin currently compares against the last build instead of the last stable build. If you get a stable build followed by a build that resolves one error and introduces one error, then this build is marked as unstable. However, if there is no change in the following build, the build status for the last build becomes stable again, because the number of new errors is zero, even though there has been one new error introduced since the last time the build was stable. This really does indicate that the comparison of new errors between each build is not right and that my original statement still stands, that the builds should always compare the current results against the last stable build. The last stable build is after all, the benchmark for where the cppcheck results need to be. If new errors have been introduced since then, then the build can't possibly be considered stable - ever. 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.
[JIRA] [cppcheck] (JENKINS-24076) Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced)
Craig Phillips commented on JENKINS-24076 Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced) This fix maintains backwards compatibility with the current strategy (which also remains the default). But it adds the option to change the behaviour such that it compares the current report against the last "stable" report. https://github.com/iwonbigbro/cppcheck-plugin/commit/d639413bf2b06c47ffa14cf3e2fe8c70073faa76 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.
[JIRA] [cppcheck] (JENKINS-24076) Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced)
Michal Turek stopped work on JENKINS-24076 Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced) Change By: Michal Turek (10/Sep/14 6:45 PM) Status: InProgress Open 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.
[JIRA] [cppcheck] (JENKINS-24076) Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced)
Michal Turek commented on JENKINS-24076 Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced) 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: What should happen in your proposal if unit tests (or whatever else) make the build unstable instead of Cppcheck? What to do with the missing history containing the last stable build, do you plan to change data model to store the deltas too? If somebody fixes one of the 100 original issues by happy accident, the threshold should be updated to 99. Newly introduced issue may be a serious memory leak or whatever but the build will be still reported as stable and the "delta with last stable build" approach will seriously fail. Feel free to create a feature branch for this task and send a pull request. That's just my two cents. 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.
[JIRA] [cppcheck] (JENKINS-24076) Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced)
Michal Turek updated JENKINS-24076 Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced) Change By: Michal Turek (10/Sep/14 6:47 PM) Issue Type: Bug NewFeature Priority: Critical Major 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.
[JIRA] [cppcheck] (JENKINS-24076) Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced)
Michal Turek assigned JENKINS-24076 to Craig Phillips Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced) Change By: Michal Turek (10/Sep/14 6:46 PM) Assignee: MichalTurek CraigPhillips 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.
[JIRA] [cppcheck] (JENKINS-24076) Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced)
Michal Turek edited a comment on JENKINS-24076 Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced) 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 belong to the "to fix" category. Does it make sense? Surely, feel free to create a feature branch for this task and send a pull request. Questions: What should happen in your proposal if unit tests (or whatever else) make the build unstable instead of Cppcheck? What to do with the missing history containing the last stable build, do you plan to change data model to store the deltas too? If somebody fixes one of the 100 original issues by happy accident, the threshold should be updated to 99. Newly introduced issue may be a serious memory leak or whatever but the build will be still reported as stable and the "delta with last stable build" approach will seriously fail. That's just my two cents. 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.
[JIRA] [cppcheck] (JENKINS-24076) Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced)
Craig Phillips commented on JENKINS-24076 Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced) Well, now the WHAT is out of the way, if you care to hear the WHY, it might help you understand my blight. In an ideal project scenario, you would set-up CPP check from the outset, ensuring you have very few errors. However, I joined a large system project and implemented CPP check very late in the day. There are some lines of code that are more than 30 years old! With that in mind, you might appreciate there being lots of warnings and errors. Unfortunately, there are thousands of errors as opposed to hundreds. Whilst we could ignore them, we actually want to fix them all, in time. I have filtered out about 1 errors, leaving around 2500 errors I think should be fixed. However, time is not on our side, so what I have implemented is a Jenkins post build step that actually uses the Jenkins CLI to reduce the threshold after each build, whenever someone fixes a warning or error. This ensures we can't introduce any new errors and continue to fix the existing errors. So as you might imagine, when there are thousands of errors, it's extremely difficult to see the wood through the trees, or as in our case, the new errors amongst the unchanged errors. We are getting there, but very slowly, which is why it's such a pain when a new error is introduced but not spotted before the next build is churned out by CI. With collaboration occurring round the clock and around the globe, it's difficult to co-ordinate commits with builds, resulting in builds very quickly pushing out the deltas before we've had a chance to look at them, especially over a weekend. We're looking to increase the number of builds we keep, but we build deployment images as part of the build, which requires lots of space, so keeping more than ten becomes a bit tricky. As I say, I'm happy to provide a generic solution, it'll just take me some time to fit around my usual workload. 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.
[JIRA] [cppcheck] (JENKINS-24076) Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced)
Craig Phillips commented on JENKINS-24076 Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced) 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. 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.
[JIRA] [cppcheck] (JENKINS-24076) Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced)
Michal Turek started work on JENKINS-24076 Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced) Change By: Michal Turek (07/Sep/14 5:05 PM) Status: Open InProgress 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.
[JIRA] [cppcheck] (JENKINS-24076) Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced)
Michal Turek commented on JENKINS-24076 Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced) Hi Craig, I read all of the comments several times and I think you misunderstood the behavior of the plugin a lot. Actually it's much simpler than you expect. All builds are independent, they share no data. Each build stores only the data that were generated during its run. If you delete a build (or let Jenkins to delete it), all of its data will be lost so the plugin will be unable to use them. Prolong the history to store more builds or to store them for longer time if you need them. Delta is computed dynamically while presenting the results. The currently displayed build and the previous one is used (N and N-1 if exists). It is for example build 50 and 49. If you delete 49 then build 50 and 48 will be used. This can be changed to go deeper in the history and skip builds with no Cppcheck data, e.g. the failed ones. The plugin doesn't consider last stable build, last unstable build, etc. at all. It is surely possible to have zero delta together with non-zero count of new/solved issue. For example if 5 style issues are solved and 5 new ones introduced, the delta will be zero. Unfortunatelly I can't determine if this is the case, the screenshot is incomplete. Did you consider to use any of these Cppcheck options? I guess they can help you a lot. --inline-suppr Enable inline suppressions. Use them by placing comments in the form: // cppcheck-suppress memleak before the line to suppress. --suppress=spec Suppress a specific warning. The format of spec is: [error id]:[filename]:[line]. The [filename] and [line] are optional. [error id] may be * to suppress all warnings (for a specified file or files). [filename] may contain the wildcard characters * or ?. --suppressions-list=file Suppress warnings listed in the file. Each suppression is in the format of spec above. 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.
[JIRA] [cppcheck] (JENKINS-24076) Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced)
Craig Phillips commented on JENKINS-24076 Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced) Hi. Thanks for the info. I'll see if I can get a build set-up for the plugin and debug it. 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.
[JIRA] [cppcheck] (JENKINS-24076) Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced)
Michal Turek commented on JENKINS-24076 Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced) Hi, I will look at the issue, but I have no time for that at the moment. If you are really desperate, you can debug and fix the issue by yourself and create a pull request. The related code is org.jenkinsci.plugins.cppcheck.CppcheckResult.getDiff() for summary and diffCurrentAndPrevious() for details. Data of previous build comes from getPreviousResult(), I guess there should be loop to the builds history instead of single if condition. I have updated similar code in sloccount plugin, it may be the same. The report is initially parsed and stored in org.jenkinsci.plugins.cppcheck.CppcheckPublisher.perform(). Hope this will help for quick orientation in the code... 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.
[JIRA] [cppcheck] (JENKINS-24076) Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced)
Craig Phillips assigned JENKINS-24076 to Michal Turek Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced) There hasn't been any movement on this issue and we are desperate for a fix. Any chance you could take a look. Thanks. Change By: Craig Phillips (19/Aug/14 10:36 AM) Assignee: GregoryBoissinot MichalTurek 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.
[JIRA] [cppcheck] (JENKINS-24076) Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced)
Craig Phillips updated JENKINS-24076 Incorrect builds used to generate deltas (No deltas for builds fixed after failure where errors were introduced) Change By: Craig Phillips (14/Aug/14 8:01 AM) Summary: Incorrectbuildsusedtogeneratedeltas (Nodeltasforbuildsfixedafterfailurewhereerrorswereintroduced) Priority: Major Critical 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.
