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

Add precision option for the "Stability auto update"/"Health auto update" options

XMLWordPrintable

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Major Major
    • cobertura-plugin
    • None

      The options "Stability auto update"/"Health auto update" are quite useful for legacy projects. But getting an unstable build, because the coverage decreased from 21.35 to 21.34 doesn't increase acceptance of this feature.
      I'd like a lesser precision like 21.3 or 21.

          [JENKINS-23183] Add precision option for the "Stability auto update"/"Health auto update" options

          Christof Schablinski created issue -

          Fadel Wanssa added a comment - - edited

          Maybe an option to set build unstable if coverage decreases by a certain percentage or value compared to previous build (ex: if code coverage drops by 2% from previous build, set build to unstable).

          Fadel Wanssa added a comment - - edited Maybe an option to set build unstable if coverage decreases by a certain percentage or value compared to previous build (ex: if code coverage drops by 2% from previous build, set build to unstable).

          Sorin Sbarnea added a comment -

          I totally agree with this as now we get 50% of the builds failed even when a single line of code is modified, just because of the rounding errors.

          The situation is even worse because exporting status via cc.xml files (CCTray) supports only success and failed, and the unstable is mapped as a failure without any way of changing this. So we see lots of "red" builds just because the code coverage went from 99.99% to 99.98%. Clearly the threshold for measuring a decrease should be a percent, not a "rounding error".

          Sorin Sbarnea added a comment - I totally agree with this as now we get 50% of the builds failed even when a single line of code is modified, just because of the rounding errors. The situation is even worse because exporting status via cc.xml files (CCTray) supports only success and failed, and the unstable is mapped as a failure without any way of changing this. So we see lots of "red" builds just because the code coverage went from 99.99% to 99.98%. Clearly the threshold for measuring a decrease should be a percent, not a "rounding error".
          Sorin Sbarnea made changes -
          Remote Link New: This issue links to "github-issue-51 (Web Link)" [ 14065 ]

          Stephen Connolly added a comment -

          Last two releases (separated by over a year) were by olivergondza so looks like the maintainer

          Stephen Connolly added a comment - Last two releases (separated by over a year) were by olivergondza so looks like the maintainer
          Stephen Connolly made changes -
          Assignee Original: Stephen Connolly [ stephenconnolly ] New: Oliver Gondža [ olivergondza ]
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 155715 ] New: JNJira + In-Review [ 179104 ]
          Oliver Gondža made changes -
          Assignee Original: Oliver Gondža [ olivergondza ]

            Unassigned Unassigned
            cschablin Christof Schablinski
            Votes:
            3 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: