The timeout setting in Pipelines is the maximum time after which pipeline steps will timeout. If the step does not complete in the given time limit, it is forced to completion with a timed out status.
Setting a timeout is useful for steps that are expected to run for a shorter duration. For example, in a pipeline, Step A is expected to run for only 3 minutes, but Step B and Step C are expected to run for 45 minutes. In this case, setting the timeout for Step A to around five minutes ensures that even if the step gets trapped in a retry loop, the other, non-dependent steps, can execute after the timeout.
Timeouts can be set at the following levels and are applied according to a preset order of precedence:
Level | Precedence | |
|---|---|---|
Step | 1 | Highest |
Node Pool | 2 | |
System | 3 | Lowest |
Extending our example further:
Step A and Step B are configured to run on Node Pool A, and Step C is configured on run on Node Pool B
Node Pool A has its timeout set to 3600 seconds (60 minutes)
Node Pool B has no timeout set
Step A has its timeout value set to 300 seconds (5 minutes) in the pipelines yaml
Step B and Step C have no timeout set in the pipelines yaml
The timeout in the system yaml is set to 7200000 milliseconds (120 minutes)
Now, when the pipeline runs:
Step A has 5 minutes before timing out. Due to the order of precedence, it ignores the timeout set for Node Pool A and the system yaml, both of which have higher timeout values.
Step B has 60 minutes before timing out, since that is the value set for Node Pool A. It ignores the value set in the system yaml.
Step C has 120 minutes before timing out, since that is the value set in the system yaml.