Overview
Recently we introduced support for Failure Strategies, which allows developers to implement more powerful logic and control flow into their workflows. Today, we are excited to announce a new step failure strategy, retry, which can auto-retry your failed steps without requiring any input from the user.
No matter what happens to your step, whether it failed because of flaky tests or unexpected network issues, the retry failure strategy will automatically retry the step for you until it passes or reaches the configured maximum retry count. These retries will all be scheduled natively within the same pipeline run.
On top of it, we are also bringing failure strategy support to the parent level of parallel groups and stages, allowing users to apply strategies to more steps at once with a single .yaml property.
Quick start
As with all failure strategies, you can use the on-fail option to configure a new retry strategy:
- step:
on-fail:
strategy: retry
// Other optionsBy default, it will retry your step one time, but you can configure it to retry up to 10 times in order to maximise the likelihood of the step passing.
- step:
on-fail:
strategy: retry
maxRetryCount: 3 // This can be an integer from 1-10
// Other optionsIf the step does not pass within the specified retry limit, the pipeline will fail as it usually would.
Visual updates
Just like the ignore failure strategy, we will communicate the effect of the retry failure strategy within the step card on the Pipelines view.
You can hover on the “<currentRetry> of <maxRetryCount>” label to view more details on why it was retried. Hovering on the build duration will also provide the total consumed build minutes and run duration, including from retries.
Note: Automatically retried steps will consume additional build minutes.
Support for stages and parallel groups
Stages and parallel groups are some of the most used pipeline features. They play a vital roles in complicated pipelines, helping developers speed up builds and grouping steps with context. We are excited to introduce the on-fail option for parallel groups and stages to provide you with even more flexibility in building pipelines.
The on-fail strategy can be set at the parallel or stage level, and will be inherited by all steps executed within the group. However, individual steps can overwrite the inherited strategy if desired, by specifying their own failure strategy at the step level.
Here is a full example of combining different types of failure strategies within a parallel group:
pipelines:
default:
- parallel:
on-fail:
strategy: retry
maxRetryCount: 2
steps:
- step:
name: "Flaky test 1"
script:
- ./test.sh 1
- step:
on-fail:
strategy: retry
maxRetryCount: 3 # You can overwrite the maximum retry count.
name: "Flaky test 2"
script:
- ./test.sh 2
- step:
on-fail:
strategy: ignore # You can even overwrite the strategy type
name: "Flaky test 3 (ignore)"
script:
- ./test.sh 3And here is what it looks like in your pipeline list:
Important Note:
Failure strategies are not “additive”, meaning a step can only have a single strategy applied to it at any one time.
For example, if a step within a stage has the retry strategy, but the stage it is part of has ignore, the step’s strategy will take precedent and the build will fail if the step exhausts it’s maximum retry allowance.
It will not retry X times, and then fall-back to the higher-level strategy of ignore.
Compatibility and limitations
In this release, we are releasing the retry strategy, which shares some of the limitations of the ignore strategy:
- Deployment steps or deployment stages won’t support the
retrystrategy for now. - The
retrystrategy is not compatible withfail-fast, they are mutually exclusive within the same parallel group.
Feedback
We’re always keen to hear your thoughts and feedback – if you have any questions or suggestions on the failure strategy, feel free to share via the Pipelines Community Space.