Set PipelineRun Tasks to inherit their timeout from their PipelineRun's spec.timeouts.pipeline

[aThorp96]

Feature request

Based on the Pipelines docs it appears that previously a Task would inherit its timeout from pipelinerun.spec.timeout if unspecified. That field is now deprecated, and its new functional equivalent is pipelinerun.spec.timeouts.pipeline. I propose that a Pipeline's Task's default timeout still be the (functional) Pipeline timeout, instead of defaulting to the TektonConfig default-timeout-minutes. I believe this is an intuitive expectation of the default value. This of course does not offer any net-new functionality but improves the ergonomics of the user.

Use case

Example of potential perceived regression

• User starts with the pipeline:

apiVersion: tekton.dev/v1
kind: PipelineRun
  name: some-run
  namespace: cool-namespace-uwu
spec:
  timeout: "24h"
  pipelineSpec:
    tasks:
      - name: sleepy
        taskSpec:
          steps:
            - name: sleep
              image: ubuntu
              script: |
                #!/usr/bin/env bash
                sleep 12h && echo "yawn" 

• User sees that spec.timeout is deprecated and updates their spec:

-  timeout: "24h"
+  timeouts:
+    pipeline: "24h"

• spec.pipelineSpec.tasks[0] now uses the default timeout minutes 60m, causing it to timeout where it did not before

General use-case, ergonomics

When a pipeline takes longer than the default timeout due to one or more of the tasks taking longer than the tiemout, an intuitive solution would be to simply raise the PipelineRun's timeouts.pipeline and/or timeouts.tasks. However this will not have the desired effect as the long-running tasks will still keep the default timeout.

[vdemeester]

Related issues:

• Add the ability to override the timeout value for individual pipeline tasks via taskRunSpecs in a pipelineRun #7752
• Overriding Pipeline timeout does not work #8114
• Possibly others…

[vdemeester]

cc @tektoncd/core-maintainers @tektoncd/core-collaborators