Details
-
Type:
Bug
-
Status: Closed (View Workflow)
-
Priority:
Major
-
Resolution: Won't Fix
-
Component/s: analysis-collector-plugin, analysis-core-plugin, findbugs-plugin
-
Labels:None
-
Environment:Hudson 1.352, Static Analysis Utilities 1.4, Static Analysis Collector Plug-in 1.2
-
Similar Issues:
Description
We're doing incremental Maven multi-module builds in Hudson (m2 job type), and I've noticed the following behavior: When a particular module in the multi-module build doesn't run (because it hasn't changed), the static analysis plugins for the top-level build report that all of that module's warnings, FindBugs issues, etc. have been resolved. I understand why this is happening, but it's a bit frustrating – the only way we can get accurate trending for static analysis reports is by forcing a full (and lengthy) rebuild whenever any module is changed.
Theoretically, couldn't the analysis utilities recognize builds that didn't execute (as opposed to builds that failed) and use the results from the most recent executed build? It seems (although I have no idea what the code looks like) as if those results should be available in some form, since they're necessary to generate the trend graphs.
Attachments
Activity
We're experiencing the same behavior, that immensely hinders our struggle to reduce build times in our Maven multi-module project, while getting the most out of the great static analysis features. Are there any suggestions how to work around this issue for now?
Jenkins 1.470
Static Analysis Utilities 1.42
Static Analysis Collector Plug-in 1.28
Sven Amann
added a comment - We're experiencing the same behavior, that immensely hinders our struggle to reduce build times in our Maven multi-module project, while getting the most out of the great static analysis features. Are there any suggestions how to work around this issue for now?
Jenkins 1.470
Static Analysis Utilities 1.42
Static Analysis Collector Plug-in 1.28 I have a similar problem (analysis plugins report all bugs closed) in a multi-module project, however it is due to maven-release-plugin (rather than incremental builds). During normal SCM-triggered builds, analysis/trends work great, but when a manually triggered Maven Release build is run, it looks as though Maven release:perform goal cleans the workspace just before the post-build actions.
Example of what is displayed on the job/build dashboard:
(build #11/normal) Task Scanner: 12 open tasks in 102 workspace files. 12 new open tasks
(build #12/release) Task Scanner: 0 open tasks in 1 workspace file. 12 closed tasks
(build #13/normal) Task Scanner: 12 open tasks in 102 workspace files. 12 new open tasks
(build #14/release) Task Scanner: 0 open tasks in 1 workspace file. 12 closed tasks
...and the trend graph is sawtooth.
Gerald Turner
added a comment - I have a similar problem (analysis plugins report all bugs closed) in a multi-module project, however it is due to maven-release-plugin (rather than incremental builds). During normal SCM-triggered builds, analysis/trends work great, but when a manually triggered Maven Release build is run, it looks as though Maven release:perform goal cleans the workspace just before the post-build actions.
Example of what is displayed on the job/build dashboard:
(build #11/normal) Task Scanner: 12 open tasks in 102 workspace files. 12 new open tasks
(build #12/release) Task Scanner: 0 open tasks in 1 workspace file. 12 closed tasks
(build #13/normal) Task Scanner: 12 open tasks in 102 workspace files. 12 new open tasks
(build #14/release) Task Scanner: 0 open tasks in 1 workspace file. 12 closed tasks
...and the trend graph is sawtooth. The plugin is deprecated and not maintained anymore. Please upgrade to the warnings-ng plugin.
I've also been struck by this behavior. Nothing special here - a simple multi module m2 project job with "incremental build" enabled. Subsequent rebuilds not involving all modules result in an unusual fluctuations of detected warnings/task/pmd violations/findbugs smells etc. It would be great if the aggregated overall project static code analysis results depended not only on the results obtained during build of changed modules but rather aggregate them along with all recent results from untouched modules.
Changing this issue's component to the more appropriate one and issue type to bug rather than improvement.