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

Option for Trendgraph to ignore failed builds

    Details

    • Type: Improvement
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Component/s: warnings-plugin
    • Labels:
      None

      Description

      If the warnings scanner is also active on failed builds (for example to get a quick overview of compiler errors) the trendgraph gets "down" dependent on where on the build progress the build failed.
      It would be nice to have an Option, which allows the parsing of warnings on failed builds, but exclude this data for threndgraph and calculation of "new" warnings.

      Maybe an option like: [ ] only show high priority warnings on failed builds
      or something like this.

        Issue Links

          Activity

          laeubi Christoph Läubrich created issue -
          Hide
          drulli Ulli Hafner added a comment -

          Do you think it makes sense to have an option for this behaviour? Shouldn't failed build be always excluded from trend graphs?

          I'm not sure why this should influence the new warnings? Can you elaborate this part somewhat?

          Show
          drulli Ulli Hafner added a comment - Do you think it makes sense to have an option for this behaviour? Shouldn't failed build be always excluded from trend graphs? I'm not sure why this should influence the new warnings? Can you elaborate this part somewhat?
          Hide
          laeubi Christoph Läubrich added a comment -

          Yes, I agree that failed builds should always be excluded from builds. The Problem is, that currently there are only two option:
          1) Don't run the Warningsblugin on failed build (so disable the "always run this plugin" option in the advanced options
          2) Enable the Option and let it run regardles of the failure of the build.

          With Option 1 everything with the trendgraph/new warnings is okay, except that when a build fails you manually have to scan the console output to see what is going wrong, thats why I use option 2, this creates "High Priority Warnings" for compile errors that could be easily reviewed (and fixed of course .

          The problem with option 1 is the following:
          Assume a build with 100 Sourcefiles each one generates a warning so if everything is fine it says 100 warnings, 0 new, 0 fixed.
          When the build fails, lets say after the 20th file it says 21 Warnings (20 'normal' one 'high') 1 new, 80 fixed.
          When the build gets okay again it compiles all files and say 100 Warnings, 80 new 1 fixed.
          The Trendgraph then has a "peak" down and up for this broken build als well as the new/fixed ration is missleading.

          So what would be nice is a combination of 1+2 which parses (and shows) the warnings on a failed so they could be reviewed, but behaves like this build never happens on the trendgraph/difference calculation.

          I hope this makes things a little more clean, if prefereable I can attatch some screenshots but they would be in german if thats okay.

          Show
          laeubi Christoph Läubrich added a comment - Yes, I agree that failed builds should always be excluded from builds. The Problem is, that currently there are only two option: 1) Don't run the Warningsblugin on failed build (so disable the "always run this plugin" option in the advanced options 2) Enable the Option and let it run regardles of the failure of the build. With Option 1 everything with the trendgraph/new warnings is okay, except that when a build fails you manually have to scan the console output to see what is going wrong, thats why I use option 2, this creates "High Priority Warnings" for compile errors that could be easily reviewed (and fixed of course . The problem with option 1 is the following: Assume a build with 100 Sourcefiles each one generates a warning so if everything is fine it says 100 warnings, 0 new, 0 fixed. When the build fails, lets say after the 20th file it says 21 Warnings (20 'normal' one 'high') 1 new, 80 fixed. When the build gets okay again it compiles all files and say 100 Warnings, 80 new 1 fixed. The Trendgraph then has a "peak" down and up for this broken build als well as the new/fixed ration is missleading. So what would be nice is a combination of 1+2 which parses (and shows) the warnings on a failed so they could be reviewed, but behaves like this build never happens on the trendgraph/difference calculation. I hope this makes things a little more clean, if prefereable I can attatch some screenshots but they would be in german if thats okay.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in jenkins
          User: Ulli Hafner
          Path:
          src/main/java/hudson/plugins/analysis/core/BuildHistory.java
          src/test/java/hudson/plugins/analysis/core/BuildHistoryTest.java
          http://jenkins-ci.org/commit/analysis-core-plugin/96ad36e7c6c6f06de201204131aa150785b4f52d
          Log:
          [FIXED JENKINS-10682] Ignore failed (or aborted) builds when computing
          the history information. I.e., failed builds will not be considered
          during new warnings evaluation and in trend graphs.

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Ulli Hafner Path: src/main/java/hudson/plugins/analysis/core/BuildHistory.java src/test/java/hudson/plugins/analysis/core/BuildHistoryTest.java http://jenkins-ci.org/commit/analysis-core-plugin/96ad36e7c6c6f06de201204131aa150785b4f52d Log: [FIXED JENKINS-10682] Ignore failed (or aborted) builds when computing the history information. I.e., failed builds will not be considered during new warnings evaluation and in trend graphs.
          scm_issue_link SCM/JIRA link daemon made changes -
          Field Original Value New Value
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Fixed [ 1 ]
          Hide
          dogfood dogfood added a comment -
          Show
          dogfood dogfood added a comment - Integrated in plugins_analysis-core #159
          drulli Ulli Hafner made changes -
          Link This issue depends on JENKINS-14867 [ JENKINS-14867 ]
          drulli Ulli Hafner made changes -
          Link This issue depends on JENKINS-14867 [ JENKINS-14867 ]
          drulli Ulli Hafner made changes -
          Link This issue is related to JENKINS-14867 [ JENKINS-14867 ]

            People

            • Assignee:
              drulli Ulli Hafner
              Reporter:
              laeubi Christoph Läubrich
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: