Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-6122

Analysis plugins should recognize non-changed modules in multimodule builds

    Details

    • 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

          Hide
          ddrzewo ddrzewo added a comment -

          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.

          Show
          ddrzewo ddrzewo added a comment - 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.
          Hide
          salsolatragus 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

          Show
          salsolatragus 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
          Hide
          gturner 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.

          Show
          gturner 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.

            People

            • Assignee:
              Unassigned
              Reporter:
              juliangraham juliangraham
            • Votes:
              11 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated: