Details
-
New Feature
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Fixed
-
None
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
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. |
Component/s | analysis-core [ 15709 ] |
Resolution | Fixed [ 1 ] | |
Status | Open [ 1 ] | Resolved [ 5 ] |
Workflow | JNJira [ 145756 ] | JNJira + In-Review [ 191615 ] |
I think this is not possible yet.
There are two ways to implement that feature: either do not consider unstable builds when computing the reference build number (which is used for comparison). Or don't compute a checkstyle result when a build is unstable (currently there already is an option to run the analysis for "UNSTABLE or SUCCESS", or "UNSTABLE or SUCCESS or FAILURE"). I.e. the checkbox needs to be replaced by a radio button.
If you are interested in contributing please provide a pull request. It would be nice if the change could be made as part of the analysis-core plug-in thus that all other analysis plug-ins will inherit the new behavior.