For example, in a pipeline, you can do something like:

try {
sh "some-command"
catch (err) {
"do stuff"
}

In a regular build, you would run shell script as part of the main build steps, and when the shell returns with a negative error code, the build result would become failure.

However, the warnings plugin is run via the generic "step()" pipeline, and instead of returning an error or throwing an exception, the step literally sets the build status. This doesn't work in parallel since the whole build has a single status, and each parallel branch might result in different build status, and thus conflict.

What I want is a new "scanWarnings" step which is a pipeline specific step we could call, and it would throw an exception, which we could catch in the pipeline code.

It might be worth getting some input from someone who uses pipelines more?

I found some documentation about doing this: https://github.com/jenkinsci/workflow-step-api-plugin/blob/master/README.md.

Right, that outline is how to add a new step which is pretty much what we want to do, I think. Ideally we would have some way of actually obtaining the results of the warnings directly in groovy so that the groovy code could make all the decisions based on those results.

Specifically, what I want is to be able to get the WarningsResult for a given run of the warnings step, so I can encode the logic of how to respond to warnings inside the pipeline code.

I need to be able to run 8 nodes in parallel, each compiling on a different distribution, and see warnings for each one, and I'd like to be able to individually label the files as "UNSTABLE" without racing against other warning results. The current problem is that currentBuild.result doesn't work well because any of the 8 nodes could finish first, and make the build result Unstable, which means I could label the wrong files as unstable, when that node didn't produce warnings.

I want a way to programatically say "this node had warnings, and this one didn't"

This is quite related to the other pipeline requirements. I think I need to split the whole reporting code into several steps that can be used independently from each other in a pipeline.

Note that this can't even be done currently with the currentBuild.rawBuild manually. Even if you manage to get the actions, there's no way to tell which WarningsResultAction actually contains the warnings you care about, since the ParserResult doesn't store which workspace files it scans.

Actually, I think all you need to do is create a step which takes a parser configuration and creatse a FileParser object, execute it, and return the ParserResult... That might not be too complicated.

That is exactly what I mean. I think I will write down these ideas in a wiki page so that everybody can help to refine these requirements before I can start with an implementation...

I'm trying to consolidate the requirements for the static analysis suite in pipeline jobs in a wiki page. Can you please read it carefully and comment or change it accordingly?

Released in 5.0.0-beta2.