Repository navigation
Add retry feature #1540
Description
Make commands retryable:
...
tasks:
build:
retry:
attempts: 3
exit_codes:
- 1
- 127
cmds:
...
If exit_codes is provided, only the provided exit codes are retryable. otherwise, all exit code are retried.
I have a use case, where a task runs many other tasks via deps. One of them fails, it all fails. In the end, CI retrys the entire task invocation, which will again run all of these parallel tasks. However, it would be much better to only retry the individual task that fails.
I can do the retry within the cmd, but that's not very elegant and re-usable i feel.
Activity
danilobuerger commentedon Jun 18, 2024
Best case, this should also include a delay.
trulede commentedon Feb 27, 2026
The situation as you describe is resolved by using Task features such as 'sources', 'generates', and 'run'. Subsequent runs of Task will not execute the previously completed tasks. There are additional features 'status', 'preconditions' and 'if' that may also be used.
If you have a particularly flaky command, simply use a shell loop. They are easy to write, concise and capable. But otherwise, use the existing features of Task.
ssbarnea commentedon Jun 10, 2026
This is marked as done but from the thread I don't see a clear pattern on how to implement a retry logic. I think that the subject is important enough to at least have an example inside the docs.
I am facing some flaky CI issues with a particular step and running it with retries can prove very useful. Using shell loop is not an option when you run taskfile across all 3 major architectures.
tbrandenburg commentedon Oct 24, 2026
I would like to revisit native retries, particularly for flaky tasks used in CI/CD and nested task workflows.
The existing sources, generates, and run features help avoid repeating completed work, but they do not provide retry semantics for a failed operation.
Shell loops work as a workaround, but they make retry policies harder to reuse, configure, and observe consistently across Taskfiles.
Would you consider a small, opt-in retry policy such as:
This is illustrative syntax, not an existing feature.
Some useful semantics would be:
I understand that retries can be unsafe for commands with side effects, so this should be explicitly opt-in.
Would you as maintainers be open to reconsidering this as a narrowly scoped enhancement? Or is native retry support intentionally outside Task’s scope?
trulede commentedon Oct 25, 2026
@tbrandenburg did you ever try
curl? Something like this: