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

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

    XMLWordPrintable

Details

    Description

      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.

      Attachments

        Issue Links

          Activity

            fadlwa 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).

            fadlwa 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).
            ssbarnea 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".

            ssbarnea 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".

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

            stephenconnolly Stephen Connolly added a comment - Last two releases (separated by over a year) were by olivergondza so looks like the maintainer

            People

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

              Dates

                Created:
                Updated: