Hi Jesse, 
thanks a lot for your comments; I hope the penny has dropped now (see 
below...).

You were right -- there was still a `setResult(ABORTED)` call preceding the 
exception in the plugin. This survives in pipeline mode buts gets 
overwritten in a Freestyle project which caused the observed inconsistency.

>From what I understand, the build result mechanism works as follows:
* Within a  `run`-method of a step I can call run.setResult() with an 
argument of type SUCCESS, UNSTABLE or FAILURE -- depending on the outcome I 
want to indicate. 
* In case of an error that is still "normal" in terms that I might happen 
during a build process but is such severe that I want to abort the build I 
throw an Exception e.g. of type AbortException. Jenkins, in turn, marks 
such builds as FAILED. 
* The other two possible outcomes, namely ABORTED or NOT_BUILD are beyond 
the scope of "normal" build execution and as such there should be in 
general no need to set them from a run method of a step. This is probably 
also the reason why one can specify an (abnormal) cause when triggering an 
build that should be treated as ABORTED. 

Is this correct now? This would still leave an ambiguity between "failed, 
but completed" and "normally aborted" (which gets also marked as failed) 
builds but apart from this it looks rather consistent...

Jesse Glick schrieb am Mittwoch, 29. Juli 2020 um 16:41:26 UTC+2:

> On Wed, Jul 29, 2020 at 8:44 AM Philipp Mahlberg
> <[email protected]> wrote:
> > run.setResult(jenkinsResult);
>
> Do not call `setResult`. Use exceptions only.
>
> > In pipeline mode, this works as expected. The first line is not even 
> needed, even without it, the build stops and will be marked as ABORTED.
>
> Must be a mistake. `AbortException`, despite the name, should produce
> `Result.FAILURE`. It is the stock marker for a build which failed not
> due to any bug in Jenkins (an expected failure), so no stack trace is
> printed.
>
> > I know that I can achieve the ABORT state by "interrupting" the build. 
> But interrupting seems to encode the user actively stopping the build e.g. 
> by clicking the red cross.
>
> For Pipeline builds, `FlowInterruptedException` encodes a cause and a
> result, defaulting to `ABORTED`. There is no exact equivalent for
> traditional job types but (IIRC) any `InterruptedException` will count
> as `ABORTED`.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/fbf2266a-a448-4ecd-ae29-6393c592bb2dn%40googlegroups.com.

Reply via email to