You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We stumbled upon the retries feature for tasks within a pipeline.
However, the retries field requires an integer value, which you can currently only hard code as a pipeline developer (according to my knowlege).
Trying to define an integer type parameter or coercing a string type parameter does not work.
Draft code of desired feature (this is not a full PipelineSpec!):
kind: Pipeline
spec:
params:
- name: retries-docker-build
description: >
Retry amount of the docker-build step in case of an error.
Specifying 0 means - no retries!
type: integer
default: 0
tasks:
- name: "docker-build"
retries: $(params.retries-docker-build)
Use case
Unfortunately we live in a flaky world and have to deal with unstable downloads, e.g. random connection reset errors of repositories that you have no control over.
In our case, developers reported that python builds (dependency downloads) are flaky.
We (as pipeline developers) want to provide the developers the opportunity to override the retries of selected steps, but we do not want to force upon them a specific amount of retries.
For example:
Project A: builds are very stable when it comes to infrastructure, for this project we want zero retries.
Project B: builds are very unstable when it comes to infrastructure, for this project we want three retries.
...where project A and B use the same pipelineRef.
The text was updated successfully, but these errors were encountered:
Feature request
We stumbled upon the retries feature for tasks within a pipeline.
However, the retries field requires an
integer
value, which you can currently only hard code as a pipeline developer (according to my knowlege).Trying to define an
integer
type parameter or coercing a string type parameter does not work.Draft code of desired feature (this is not a full PipelineSpec!):
Use case
Unfortunately we live in a flaky world and have to deal with unstable downloads, e.g. random connection reset errors of repositories that you have no control over.
In our case, developers reported that python builds (dependency downloads) are flaky.
We (as pipeline developers) want to provide the developers the opportunity to override the retries of selected steps, but we do not want to force upon them a specific amount of retries.
For example:
...where project A and B use the same pipelineRef.
The text was updated successfully, but these errors were encountered: