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

Option to consider only stable builds when calculating new warnings

    XMLWordPrintable

Details

    Description

      I'd like an option to only consider stable builds when computing the number of allowed warnings. Justification follows.

      Consider this scenario, where a job is configured to become unstable if the number checkstyle warnings increase by 5 or more compared to the previous build:

      1. The last Jenkins build is stable
      2. A developer commits a failing test and 10 fixed checkstyle issues. The failing test makes the build unstable.
      3. The developer reverts the commit, thus removing the failing test but increasing the number of checkstyle warnings back to the number of warnings in 1, and above the new limit computed in 2. The build is now unstable because of the checkstyle warnings.

      Is there a way to prevent a case like step 3 from failing the build? If not, I'd like the option described above. If you won't have the time to implement this in a near future, I think I could look into it.

      Attachments

        Activity

          davidparsson David Pärsson created issue -
          davidparsson David Pärsson made changes -
          Field Original Value New Value
          Description I'd like an option to only consider stable builds when computing the number of allowed warnings. Justification follows.

          Consider this scenario, where a job is configured to become unstable if the number checkstyle warnings increase by 5 or more compared to the previous build:

          1. The last Jenkins build is stable
          2. A developer commits a failing test and 10 fixed checkstyle issues. The failing test makes the build unstable.
          3. The developer reverts the commit, thus removing the failing test but increasing the number of checkstyle warnings back to the number of warnings in 1., and above the new limit computed in 2. The build is now unstable because of the checkstyle warnings.

          Is there a way to prevent a case like step 3 from failing the build? If not, I'd like the option described above. If you won't have the time to implement this in a near future, I think I could look into it.
          I'd like an option to only consider stable builds when computing the number of allowed warnings. Justification follows.

          Consider this scenario, where a job is configured to become unstable if the number checkstyle warnings increase by 5 or more compared to the previous build:

          1. The last Jenkins build is stable
          2. A developer commits a failing test and 10 fixed checkstyle issues. The failing test makes the build unstable.
          3. The developer reverts the commit, thus removing the failing test but increasing the number of checkstyle warnings back to the number of warnings in 1, and above the new limit computed in 2. The build is now unstable because of the checkstyle warnings.

          Is there a way to prevent a case like step 3 from failing the build? If not, I'd like the option described above. If you won't have the time to implement this in a near future, I think I could look into it.
          drulli Ulli Hafner made changes -
          Component/s analysis-core [ 15709 ]
          scm_issue_link SCM/JIRA link daemon made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Resolved [ 5 ]
          rtyler R. Tyler Croy made changes -
          Workflow JNJira [ 145756 ] JNJira + In-Review [ 191615 ]

          People

            drulli Ulli Hafner
            davidparsson David Pärsson
            Votes:
            1 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: