-
Improvement
-
Resolution: Fixed
-
Minor
-
None
-
Fresh Jenkins LTS 2.150.3 install
'recommended' plugins, including [Pipeline: Declarative Plugin|https://plugins.jenkins.io/pipeline-model-definition] version 1.3.6
-
-
pipeline-model-definition 1.3.7
Symptom
With a Pipeline using parallel stages with failFast true enabled, when a stage with an agent fails, the final build result is showing as ABORTED instead of FAILURE
A similar bug was recently fixed JENKINS-55459 which corrected the build status result when using non-nested parallel stages with failFast true enabled, but it seems it did not catch the case where a nested stage inside of one of the parallel stages fails.
Evidence
The fix for JENKINS-55459 was delivered under version 1.3.5 of the Pipeline: Declarative Plugin, I am testing version 1.3.6.
I started up a brand new Jenkins LTS 2.150.3 instance, with the 'recommended' plugins, including Pipeline: Declarative Plugin version 1.3.6
I ran the testcase inside of JENKINS-55459 and the build status is correctly marked as failed, so the fix from JENKINS-55459 was correct.
When I run the attached Jenkinsfile , the build still shows as ABORTED:
... ERROR: script returned exit code 1 Finished: ABORTED
Here is the full log: log
I expected the build status to be marked as FAILURE, not ABORTED.
Hypothesis
I believe the fix from JENKINS-55459 worked, but does not account for failures inside of stages with agents within the parallel stages.
- relates to
-
JENKINS-55459 failFast option for parallel stages should be able to set build result to FAILED
-
- Closed
-
- links to
I spent some time trying to reproduce this today but was not able to. Here is what I came up with as a base, but I experimented with various modifications to nesting, post stages, and swapping out error for a failing sh step but everything seemed to work fine.
I do think there could be some issues with certain kinds of agents based on LabelScript.groovy, DockerPipelineFromDockerfileScript.groovy (1, 2, and 3), and DockerPipelineScript.groovy (1, and 2), but I don't think those places would matter for the Jenkinsfile you posted (Unless maybe LabelScript is being used to run the builds on your machine and that try/catch block is being triggered).
One thing that is strange to me is that in your logs we see that the post conditions for failure and aborted both ran:
There is probably something wrong in Failure.meetsCondition, that is causing those two conditions to overlap in some cases. Maybe the new errorResult computation needs to be moved before this line so that line can check whether the errorResult matches Aborted specifically rather than just checking if error is null. Either way I think this is just a symptom of the build result being aborted in the first place, so it might not matter in practice once we figure out the other issue.