I found a comment in hudson.model.Run#setResult(Result r), saying that "result can only get worse". I partly understand the intention behind it, but this renders the manager.buildSuccess() function useless, if it's only working on previously successful builds.

There can be many use cases where you exit a step non-zero to prohibit subsequent steps from running to abort the build AND you do not want to consider the build a failure. In my case, I am using xpath on the job xml api to see if there are other builds in the queue, and if so, abort the current about-to-start fuzzer run(s) until there are no more in the queue, and then run the fuzz/negative tests so that my long-lived job is running against the latest upstream bits. I parse the log to see why it exited non-zero, and if it was a queue-flush the build should be SUCCESS and move on. I only want failed build to be ones where there were actual fuzz failures....minimize noise.

I haven't looked at the code to see why this design constraint exists, but I really hope you take my sample use case into account.

I have the exact use case as Trevor Baker.

I've filed an issue against the core component https://issues.jenkins-ci.org/browse/JENKINS-16795

use reflection
something like
manager.build.@result = hudson.model.Result.SUCCESS
works for me

I can confirm grysfeek's approach works, maybe that should be the code used in the plugin