-
New Feature
-
Resolution: Done
-
Major
-
None
-
jenkins/2.235.3 postbuildscript/2.9.1
Let's assume a job with the following Execute Scripts post build steps (this syntax is of my own invention):
postbuildSteps:
- postBuildStep1:
runIfBuildStatusIs:
- success
steps:
- buildStep1.1
- buildStep1.2
- postBuildStep2:
runIfBuildStatusIs:
- success
- failure
steps:
- buildStep2.1
- buildStep2.2
JENKINS-50799 states that if any build step of a post build step fails, then the following post build steps should still be executed. Hence, if buildStep1.1 or buildStep1.2 fails, then postBuildStep2 should still be executed, which sounds reasonable.
However, it looks like to implement this behavior (commit), the behavior of the post build script plugin was also changed to "Every build step of every post build step is executed, no matter if any build step failed." Indeed, if buildStep1.1 fails, then buildStep1.2 is also executed.
This seems inconsistent with the behavior of classical build steps outside of the post build script plugin, where each step is only executed if its predecessor succeeded. Let's assume you have a job with two build steps 1 and 2, the expected behavior is that step 2 will not run if step 1 failed.
[JENKINS-63529] Stop executing build steps in case of failure within a post build step
Hi Alex,
thanks for opening this issue. I see your arguments and my personal opinion is, that you are absolutely right. Sadly, this behavior is already established and a change could break the old behavior and affect users.
What do you think about a configuration option "Stop processing if a build step fails"? (I'm not a native speaker: Is this a good english sentence?)
Alex Cornet
added a comment - Hi Daniel,
Thanks for your quick reply. I fully agree as well that we should keep things backward compatible, so making this configurable sounds very reasonable. I'm not a native speaker either, but this phrasing sounds great to me.
What do you think of adding this config at the post build step level (as opposed to the job level) for more granular control over this feature?
Alex Cornet
added a comment - Hi Daniel,
Thanks for your quick reply. I fully agree as well that we should keep things backward compatible, so making this configurable sounds very reasonable. I'm not a native speaker either, but this phrasing sounds great to me.
What do you think of adding this config at the post build step level (as opposed to the job level) for more granular control over this feature? Yep, as granular as possible. That sounds good to me. I try to convert this ticket in a feature request and hope it's okay for you. As soon as I have time (probably the next days) I will start implementing the "feature".
Alex Cornet
added a comment - Great thanks Daniel! Sure, whatever works with your usual tracking habits is fine, I'll update the ticket name to be representative of the feature instead of the issue.
Awesome thank you, happy to help review the PR when it's out there.
Alex Cornet
added a comment - Great thanks Daniel! Sure, whatever works with your usual tracking habits is fine, I'll update the ticket name to be representative of the feature instead of the issue.
Awesome thank you, happy to help review the PR when it's out there. acornet I created a release of version 2.11.0. It will be available tomorrow. Would you be so kind and install the version tomorrow and test if your requirements are fulfilled? Thanks in advance!
Alex Cornet
added a comment - Hi dheid, I just tested this locally and this is working smoothly, thanks for sorting this out so quickly!
Best,
Alex
Alex Cornet
added a comment - Hi dheid , I just tested this locally and this is working smoothly, thanks for sorting this out so quickly!
Best,
Alex 
Assuming that you agree with the expected behavior I described, I think we just have to add a break statement under this line