[JIRA] (JENKINS-60354) Updated pipeline build step does not work with retry

[jonathan@riv.al (JIRA)]

Jonathan B created an issue

Jenkins / JENKINS-60354 Updated pipeline build step does not work with retry Issue Type: Bug Assignee: Unassigned Components: pipeline-build-step-plugin, workflow-basic-steps-plugin Created: 2019-12-03 16:54 Priority: Minor Reporter: Jonathan B We just upgraded pipeline-build-step from 2.9 to 2.10. The following no longer retries: pipeline { agent any stages { stage('bug') { steps { retry(3) { echo 'in the retry loop' //throw new Exception('failing in retry loop') // This runs (when uncommented) several times before the pipeline exits with failure. build(job: 'some/job/that/fails', propagate: true) // This only runs once before the pipeline exits with failure. } } } } } When the sub-build fails, the retry loop exits immediately and does not retry. This didn't used to happen. When raising an error in another way (e.g. the `throw new Exception`, commented out, in the code above), `retry` works as expected. Add Comment

This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)

[jonathan@riv.al (JIRA)]

Jonathan B updated an issue

Jenkins / JENKINS-60354 Updated pipeline build step does not work with retry

Change By: Jonathan B

We just upgraded pipeline-build-step from 2.9 to 2.10. The following no longer retries:

{code}

pipeline {     agent any     stages {         stage('bug') {             steps {                 retry(3) {                     echo 'in the retry loop'                     //throw new Exception('failing in retry loop') // This runs (when uncommented) several times before the pipeline exits with failure.                     build(job: 'some/job/that/fails', propagate: true) // This only runs once before the pipeline exits with failure.                 }             }         }     } }

{code}

When the sub-build fails, the retry loop exits immediately and does not retry. This didn't used to happen. When raising an error in another way (e.g. the `throw new Exception`, commented out, in the code above), `retry` works as expected.

A workaround is to try/catch the `build()` call and, in catch, `throw new Exception(...)`. If the caught exception is directly re-thrown, we see the same behavior where `retry` does not loop.

Add Comment

[dnusbaum@cloudbees.com (JIRA)]

Devin Nusbaum commented on JENKINS-60354

Re: Updated pipeline build step does not work with retry This is caused by JENKINS-49073, and difficult to fix without breaking JENKINS-44379 (unless we just revert JENKINS-49073). The cause is that Pipeline Build Step 2.10 now throws FlowInterruptedException when the build fails instead of AbortException so that it can track the result. retry ignores FlowInterruptedException for reasons discussed in JENKINS-44379 (aborting the build via an input step or the sidebar of the build should bypass retry) I'm not really sure how to fix this. I think FlowInterruptedException is overloaded with too many meanings at this point to fix it directly. One approach would be to factor out a ResultCarryingException interface, have FlowInterruptedException and some new FooException implement that interface, and then go through and switch everything that currently just uses FlowInterruptedException for a result to use ResultCarryingException when inspecting exceptions and FooException when creating them, and only use FlowInterruptedException when we only want to capture actual Pipeline interruption.

Add Comment

[dnusbaum@cloudbees.com (JIRA)]

Devin Nusbaum commented on JENKINS-60354

Re: Updated pipeline build step does not work with retry

Jesse Glick Noted in this comment that the easiest short-term fix is probably to make retry only rethrow FlowInterruptedException when there is at least one CauseOfInterruption. I did a quick investigation and I think WorkflowRun.doTerm would need to start setting a CauseOfInterruption, but didn't see any other uses that would need to be changed. He also noted that another possible fix would be to add a flag to FlowInterrupted exception to indicate actual build interruptions as opposed to otherwise-normal exceptions with a result, and have steps like retry look at that flag to decide whether to rethrow the exception. I think that would be easier than introducing new exception types as in my original idea, and a bit more robust than relying on the presence or absence of a CauseOfInterruption, although we would need to update things like the input step and have them set that flag, so it would require a bit more effort. I am also noting that catchError and warnError have the same problem as retry with the new version of build, and will ignore any errors thrown by it by default.

Add Comment