-
New Feature
-
Resolution: Duplicate
-
Minor
-
None
-
Platform: All, OS: All
Could you consider to adding this feature to the FindBugs Hudson plugin?
We would want to be able to do the following on each buld, from Hudson:
1. Perform a FindBugs analysis with little or no filtering to get the general
warning statistics (for presentation in Hudson via your plugin)
2. Filter these warnings through 1 include and 1 exclude FindBugs filter files
to get the warnings that we think are "critical" in a separate file.
3. Set you plugin up so that it would fail the build (not just mark it unstable)
on a certain number of "critical" warnings (i.e., those passing the filters in
Step 2).
4. See the results, obtained in Step 1 the normal - beautiful - way.
We don't know if you are using FindBugs itself to parse/analyze the result
files. Depending on this, you could either do Step 2 inside the plugin (the user
specifying the include and exclude filter files), or the user can use the
FindBugs filterBugs Ant task, and specify the filtered "critical" file in your
plugin UI.
Step 3 is the new functionality that only your plugin can provide.
We would be very happy to have this functionality available, and it might
benefit other users too.
- duplicates
-
-
- Resolved
-
[JENKINS-3024] A "critical" subset of FindBugs warnings to fail a build
Some details from our mail discussion:
-----------------------------------------------------------------------
Igor:
This looks good to me! It has all the generality useful for anyone.
The only extra thing we'd want for ourselves in this scheme of things is to be
able to select a different FB results xml file for failing (the one we have
stringently filtered from the general analysis results)
-----------------------------------------------------------------------
Ulli:
Since I'm currently changing the warnings threshold configuration anyway, what
about having thresholds for:
unstable (# total)
unstable (# new warnings)
failed (# total)
failed (# new warnings)
where # failed > # unstable. If nothing is defined then no action is taking place.
kutzi
added a comment - I wanted to open a feature request for this, but I think this one is similar
enough to add it as a comment (I think it is a simpler version of what was
originally requested):
I want to be able to do the following:
- have FindBugs plugin report all warnings (above a given priority) for the
health report - but only fail the build resp. mark it as unstable if a given amount of
warnings above a different given priority is exceeded.
For example, I want to see all normal and high priority warnings in the health
report, but I want the build to become unstable only, if >1 new high priority
warnings are introducted.
kutzi
added a comment - I wanted to open a feature request for this, but I think this one is similar
enough to add it as a comment (I think it is a simpler version of what was
originally requested):
I want to be able to do the following:
have FindBugs plugin report all warnings (above a given priority) for the
health report
but only fail the build resp. mark it as unstable if a given amount of
warnings above a different given priority is exceeded.
For example, I want to see all normal and high priority warnings in the health
report, but I want the build to become unstable only, if >1 new high priority
warnings are introducted. 
findbugs is not invoked by my plug-in. I'm just reading findbugs.xml files. So
the steps 1-2 should be done outside of Hudson (even better would be to have two
jobs), one with all warnings and one only with the special ones.
For step 3 I can add an option to fail rather then set to unstable even if this
does not match the Hudson concept. Why do you like to fail a build rather than
setting the build to unstable? The semantics of failure are compile failures...
Step 4 is best done with a separate job.