Not necessary to require all three pipelinerun.spec.timeouts fields

[marniks7]

Expected Behavior

I expect for finally block to be executed when PipelineRunTimeout

From the docs

finally tasks are guaranteed to be executed in parallel after all PipelineTasks under tasks have completed regardless of success or error

timeout is error scenario

Actual Behavior

finally block is NOT executed

Name:              testbnf2n
Namespace:         test
Service Account:   default
Labels:
 tekton.dev/pipeline=testbnf2n

🌡️   Status

STARTED          DURATION   STATUS
17 minutes ago   1m33s      Failed(PipelineRunTimeout)

💌 Message

PipelineRun "testbnf2n" failed to finish within "30s"

⏱  Timeouts
 Pipeline:   30s
 Finally:    10s

🗂   Taskruns

 NAME                TASK NAME   STARTED          DURATION   STATUS
 ∙ testbnf2n-sleep   sleep       17 minutes ago   46s        Succeeded

⏭️  Skipped Tasks

 NAME
 ∙ final

Steps to Reproduce the Problem

1. create

apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  generateName: test
spec:
  timeouts:
    pipeline: 30s
    finally: 10s
  pipelineSpec:
    tasks:
      - name: sleep
        taskSpec:
          steps:
            - name: sleep
              image: bash
              script: |
                sleep 40
    finally:
      - name: final
        taskSpec:
          steps:
            - name: sleep
              image: bash
              script: |
                echo "should be executed"

2. observer the results

Additional Info

• Kubernetes version:

Client Version: version.Info{Major:"1", Minor:"25", GitVersion:"v1.25.4", GitCommit:"872a965c6c6526caa949f0c6ac028ef7aff3fb78", GitTreeState:"clean", BuildDate:"2022-11-09T13:36:36Z", GoVersion:"go1.19.3", Compiler:"gc", Platform:"linux/amd64"}
Kustomize Version: v4.5.7
Server Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.11", GitCommit:"dc2898b20c6bd9602ae1c3b51333e2e4640ed249", GitTreeState:"clean", BuildDate:"2022-09-14T16:32:41Z", GoVersion:"go1.17.13", Compiler:"gc", Platform:"linux/amd64"}
WARNING: version difference between client (1.25) and server (1.23) exceeds the supported minor version skew of +/-1

• Tekton Pipeline version:

Client version: 0.26.0
Pipeline version: v0.41.0
Dashboard version: v0.30.0

[lbernick]

Thanks for filing @marniks7! I think this is intended behavior. If you'd like for your timeout to apply only to the "tasks" section of the pipeline and for your finally tasks to never time out, you can use:

timeouts:
  tasks: 30s
  finally: 0 # no timeout for finally tasks
  pipeline: 0 # no timeout for pipelinerun as a whole

[marniks7]

Hi @lbernick ,
Thanks for the answer. It is only partially possible to use suggested approach. Overall looks like there are a lot of pitfalls.

Despite docs and your example
0 value doesn't work

Error from server (BadRequest): error when creating "test.yaml": admission webhook "webhook.pipeline.tekton.dev" denied the request: mutation failed: cannot decode incoming new obj
ect: json: cannot unmarshal number into Go struct field TimeoutFields.spec.timeouts.finally of type string

"0" value doesn't work,

Error from server (BadRequest): error when creating "test.yaml": admission webhook "validation.webhook.pipeline.tekton.dev" denied the request: validation failed: invalid value: 30
s + 0s should be <= pipeline duration: spec.timeouts.finally, spec.timeouts.tasks

0s value doesn't work

Error from server (BadRequest): error when creating "test.yaml": admission webhook "validation.webhook.pipeline.tekton.dev" denied the request: validation failed: invalid value: 30
s + 0s should be <= pipeline duration: spec.timeouts.finally, spec.timeouts.tasks

This works, however I don't know what will be in case of timeouts.tasks > default-timeout-minutes

  timeouts:
    tasks: 30s

---

Based on

All three sub-fields are optional, and will be automatically processed according to the following constraint:

timeouts.pipeline >= timeouts.tasks + timeouts.finally

Config which doesn't work:

  timeouts:
    finally: 10s
    pipeline: 30s

and config which works. What is the use case for such difference to exist?

  timeouts:
    tasks: 20s
    finally: 10s
    pipeline: 30s

[lbernick]

Thanks for following up!

In #5460, we added the ability to specify only timeouts.finally or timeouts.tasks, and this is available as of v0.40.0.

Thanks for pointing out the yaml I provided doesn't quite work, sorry about that. Here's what does (just tried it out):

  timeouts:
    pipeline: "0"
    tasks: "30s"

However I think if we support this syntax we also should support this:

  timeouts:
    pipeline: "0"
    tasks: "30s"
    finally: "0"

so I'll reopen (and retitle). I also agree with you that you shouldn't necessarily have to specify timeouts.tasks if you've specified the other two timeouts.

I also opened #6171 to update our docs.

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.