-
Bug
-
Resolution: Fixed
-
Minor
-
None
-
-
workflow-basic-steps 2.19, pipeline-build-step 2.11, workflow-step-api 2.22
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.
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.
- is caused by
-
-
- Resolved
-
- relates to
-
-
- Resolved
-
-
-
- Resolved
-
-
-
- Closed
-
- links to
[JENKINS-60354] Updated pipeline build step does not work with retry, catchError, or warnError
Jonathan B
created issue -
Jonathan B
made changes -
| Description |
Original:
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. |
New:
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. |
| Link |
New:
This issue is caused by |
| Link |
New:
This issue is caused by |
| Link |
Original:
This issue is caused by |
| Link |
New:
This issue relates to |
| Link |
New:
This issue is caused by |
| Link |
Original:
This issue is caused by |
| Remote Link | New: This issue links to "Discussion of potential fixes (Web Link)" [ 24103 ] |
This is caused by
JENKINS-49073, and difficult to fix without breakingJENKINS-44379(unless we just revertJENKINS-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.