feat: override task timeouts in pipelineruns #8636

waveywaves · 2025-03-11T14:47:47Z

Changes

Submitter Checklist

As the author of this PR, please check off the items in this checklist:

Has Docs if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps
Has Tests included if any functionality added or changed
pre-commit Passed
Follows the commit message standard
Meets the Tekton contributor standards (including functionality, content, code)
Has a kind label. You can add one by adding a comment on this PR that contains /kind <type>. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of good release notes.
Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

NONE

waveywaves · 2025-03-11T14:48:26Z

/kind feature

tekton-robot · 2025-03-11T14:59:03Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/pipelinerun_types.go	92.5%	92.5%	0.1
pkg/apis/pipeline/v1/pipelinerun_validation.go	94.7%	93.8%	-0.9

tekton-robot · 2025-03-11T15:24:21Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/pipelinerun_types.go	92.5%	92.5%	0.1
pkg/apis/pipeline/v1/pipelinerun_validation.go	94.7%	93.8%	-0.9

tekton-robot · 2025-03-28T23:58:06Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/pipelinerun_types.go	92.5%	92.5%	0.1
pkg/apis/pipeline/v1/pipelinerun_validation.go	94.7%	93.8%	-0.9

tekton-robot · 2025-03-29T01:35:42Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/pipelinerun_types.go	92.5%	92.5%	0.1
pkg/apis/pipeline/v1/pipelinerun_validation.go	94.7%	94.4%	-0.2

tekton-robot · 2025-03-29T02:11:44Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/pipelinerun_types.go	92.5%	92.5%	0.1
pkg/apis/pipeline/v1/pipelinerun_validation.go	94.7%	94.4%	-0.2

tekton-robot · 2025-03-29T02:15:50Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/pipelinerun_types.go	92.5%	92.5%	0.1
pkg/apis/pipeline/v1/pipelinerun_validation.go	94.7%	94.4%	-0.2

tekton-robot · 2025-03-31T20:06:30Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/pipelinerun_types.go	92.5%	92.5%	0.1
pkg/apis/pipeline/v1/pipelinerun_validation.go	94.7%	94.4%	-0.2

tekton-robot · 2025-03-31T20:10:36Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/pipelinerun_types.go	92.5%	92.5%	0.1
pkg/apis/pipeline/v1/pipelinerun_validation.go	94.7%	94.4%	-0.2

tekton-robot · 2025-03-31T20:17:38Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/pipelinerun_types.go	92.5%	92.5%	0.1
pkg/apis/pipeline/v1/pipelinerun_validation.go	94.7%	94.4%	-0.2

waveywaves · 2025-03-31T20:37:34Z

cc @vdemeester @afrittoli @aThorp96 ready for review

vdemeester

cc @tektoncd/core-maintainers @afrittoli

tekton-robot · 2025-04-01T16:01:16Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: vdemeester

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

~~OWNERS~~ [vdemeester]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

waveywaves · 2025-04-28T21:04:29Z

cc @afrittoli @twoGiants @abayer

twoGiants

Good job @waveywaves ! 😸

My comments are nice to haves, its all implemented and tested well.

I think this PR would benefit from a documentation entry in "Specifying taskRunSpecs". You could reuse the explanation from #7752.

Let me know if I can support.

twoGiants · 2025-04-30T13:11:27Z

pkg/apis/pipeline/v1/pipelinerun_validation.go

@@ -87,6 +87,14 @@ func (ps *PipelineRunSpec) Validate(ctx context.Context) (errs *apis.FieldError)
 	// Validate propagated parameters
 	errs = errs.Also(ps.validateInlineParameters(ctx))

+	// Validate task run specs first
+	for idx, trs := range ps.TaskRunSpecs {
+		if trs.Timeout != nil && trs.Timeout.Duration < 0 {


I think this check would fit very well into validateTaskRunSpec() in line 338 after the trs.PodTeplate check. Then you would not need the loop and the call to validateTaskRunSpec in line 95 here.

I think you can also reuse validateTimeoutDuration and remove the if statement.

twoGiants · 2025-04-30T13:16:22Z

pkg/apis/pipeline/v1/pipelinerun_validation.go

@@ -103,6 +111,20 @@ func (ps *PipelineRunSpec) Validate(ctx context.Context) (errs *apis.FieldError)
 			defaultTimeout := time.Duration(config.FromContextOrDefaults(ctx).Defaults.DefaultTimeoutMinutes)
 			errs = errs.Also(ps.validatePipelineTimeout(defaultTimeout, "should be <= default timeout duration"))
 		}
+
+		if len(ps.TaskRunSpecs) > 0 {


I would extract this block into a function like the entries above and below do, it could be named: validateTaskRunSpecTimeouts and use the guard pattern, e.g.:

if len(ps.TaskRunSpecs) == 0 { return errs } //...

twoGiants · 2025-04-30T13:32:15Z

pkg/apis/pipeline/v1/pipelinerun_validation.go

+				pipelineTimeout = &metav1.Duration{Duration: time.Duration(config.FromContextOrDefaults(ctx).Defaults.DefaultTimeoutMinutes) * time.Minute}
+			}
+			for _, taskRunSpec := range ps.TaskRunSpecs {
+				if taskRunSpec.Timeout != nil {


This would also be a good place for a guard clause (or two), then the next if statement does not need to be nested :)

if taskRunSpec.Timeout == nil { continue } if pipelineTimeout.Duration == config.NoTimeoutDuration { continue } if taskRunSpec.Timeout.Duration > pipelineTimeout.Duration { errs = ... } // ...

twoGiants · 2025-04-30T13:37:01Z

pkg/apis/pipeline/v1/pipelinerun_validation_test.go

@@ -1352,6 +1391,26 @@ func TestPipelineRun_InvalidTimeouts(t *testing.T) {
 			},
 		},
 		want: apis.ErrInvalidValue(`0s (no timeout) should be <= pipeline duration`, "spec.timeouts.finally"),
+	}, {
+		name: "task-specific timeout exceeds pipeline timeout",


You could add another valid test covering the case when the pipelineTimeout.Duration == config.NoTimeoutDuration, then there should be no error when task timeout exceeds pipeline timeout.

tekton-robot · 2025-05-07T12:16:45Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/pipelinerun_types.go	92.5%	92.5%	0.1
pkg/apis/pipeline/v1/pipelinerun_validation.go	94.7%	94.4%	-0.2

tekton-robot · 2025-05-07T12:21:23Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/pipelinerun_types.go	92.5%	92.5%	0.1
pkg/apis/pipeline/v1/pipelinerun_validation.go	94.7%	93.5%	-1.2
pkg/apis/pipeline/v1/taskrun_validation.go	97.4%	97.5%	0.0
pkg/apis/pipeline/v1beta1/taskrun_validation.go	97.4%	97.5%	0.0

tekton-robot · 2025-05-07T12:26:33Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/pipelinerun_types.go	92.5%	92.5%	0.1
pkg/apis/pipeline/v1/pipelinerun_validation.go	94.7%	94.1%	-0.6
pkg/apis/pipeline/v1/taskrun_validation.go	97.4%	97.5%	0.0
pkg/apis/pipeline/v1beta1/pipelinerun_validation.go	97.2%	97.7%	0.6
pkg/apis/pipeline/v1beta1/taskrun_validation.go	97.4%	98.1%	0.7

tekton-robot · 2025-05-07T12:28:22Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/pipelinerun_types.go	92.5%	92.5%	0.1
pkg/apis/pipeline/v1/pipelinerun_validation.go	94.7%	94.1%	-0.6
pkg/apis/pipeline/v1/taskrun_validation.go	97.4%	97.5%	0.0
pkg/apis/pipeline/v1beta1/pipelinerun_validation.go	97.2%	97.7%	0.6
pkg/apis/pipeline/v1beta1/taskrun_validation.go	97.4%	98.1%	0.7

tekton-robot · 2025-05-07T12:31:56Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/pipelinerun_types.go	92.5%	92.5%	0.1
pkg/apis/pipeline/v1/pipelinerun_validation.go	94.7%	94.1%	-0.6
pkg/apis/pipeline/v1/taskrun_validation.go	97.4%	97.5%	0.0
pkg/apis/pipeline/v1beta1/pipelinerun_validation.go	97.2%	97.7%	0.6
pkg/apis/pipeline/v1beta1/taskrun_validation.go	97.4%	98.1%	0.7

waveywaves · 2025-06-03T09:49:19Z

/retest

aThorp96 · 2025-06-03T11:47:18Z

docs/pipelineruns.md

 ```
 {{% /tab %}}
 {{< /tabs >}}

 If used with this `Pipeline`,  `build-task` will use the task specific `PodTemplate` (where `nodeSelector` has `disktype` equal to `ssd`)
-along with `securityContext` from the `pipelineRun.spec.podTemplate`.
+along with `securityContext` from the `pipelineRun.spec.podTemplate`. The task will also have a specific timeout of 1 hour and 30 minutes. This overrides any existing timeout already defined by the pipelineTask as well.


Suggested change

along with `securityContext` from the `pipelineRun.spec.podTemplate`. The task will also have a specific timeout of 1 hour and 30 minutes. This overrides any existing timeout already defined by the pipelineTask as well.

along with `securityContext` from the `pipelineRun.spec.podTemplate`. The task will also have a specific timeout of 1 hour and 30 minutes. This overrides any existing timeout already defined by the pipelineTask as well, though the specified `pipelineRun.spec.timeouts.tasks` will still take precedence.

aThorp96 · 2025-06-03T11:58:07Z

pkg/apis/pipeline/v1/pipelinerun_types.go

@@ -656,6 +656,11 @@ type PipelineTaskRunSpec struct {

 	// Compute resources to use for this TaskRun
 	ComputeResources *corev1.ResourceRequirements `json:"computeResources,omitempty"`
+
+	// Time after which the TaskRun times out.


Suggested change

// Time after which the TaskRun times out.

// Time after which the TaskRun times out. Overrides the timeout specified

// on the Task's spec if specified. Takes lower precedence to PipelineRun's

// `spec.timeouts.tasks`

aThorp96 · 2025-06-03T12:10:22Z

pkg/apis/pipeline/v1/pipelinerun_validation.go

+	pipelineTimeout := ps.Timeouts.Pipeline
+	if pipelineTimeout == nil {
+		pipelineTimeout = &metav1.Duration{Duration: time.Duration(config.FromContextOrDefaults(ctx).Defaults.DefaultTimeoutMinutes) * time.Minute}
+	}


I believe this should be comparing ps.Timeouts.Tasks, and if that is not specified then falling back to ps.Timeouts.Pipeline. Since ps.Timeouts.Tasks is already enforced to be less than or equal to ps.Timeouts.Pipeline

What do you think about something like this? This implementation adds a couple things:

Creates a central timeout validation function which falls back to the default if no timeout is supplied, and if the timeout is negative then it of course fails. It DRYs up the validation for both TaskRuns schema versions and could also be used on the PipelineRun.spec.timeouts as well

PipelineRunTask timeout check now ensures that the timeout is 0 < timeout < maxTimeout where maxTimeout is the first present in: pr.spec.timeouts.tasks || pr.spec.timeouts.pipeline || defaultTimeout,

// in the PipelineValidation func validatePipelineTaskRunSpecTimeouts(ps *PipelineRunSpec, ctx context.Context) *apis.FieldError { cfg := config.FromContextOrDefaults(ctx) var errs *apis.FieldError maxTimeout := &metav1.Duration{Duration: time.Duration(cfg.Defaults.DefaultTimeoutMinutes) * time.Minute} if ps.Timeouts != nil { // Loop over max-timeouts in order of precedence to find most applicable for _, timeout := range []*metav1.Duration{ps.Timeouts.Tasks, ps.Timeouts.Pipeline} { if timeout != nil { timeout, err := validateTimeout(ps.Timeouts.Tasks, cfg.Defaults.DefaultTimeoutMinutes) if err != nil { return errs.Also(err) } maxTimeout = timeout break } } } if maxTimeout.Duration == config.NoTimeoutDuration || len(ps.TaskRunSpecs) == 0 { return errs } for _, taskRunSpec := range ps.TaskRunSpecs { taskRunTimeout, err := validateTimeout(taskRunSpec.Timeout, cfg.Defaults.DefaultTimeoutMinutes) if err != nil { errs = errs.Also(err) } else if taskRunTimeout.Duration > maxTimeout.Duration { errs = errs.Also(apis.ErrInvalidValue(fmt.Sprintf("%s should be <= pipeline tasks duration %s", &taskRunTimeout.Duration, maxTimeout.Duration), "taskRunSpecs["+taskRunSpec.PipelineTaskName+"].timeout")) } } return errs } // In the TaskRun validation func (ts *TaskRunSpec) Validate(ctx context.Context) (errs *apis.FieldError) { cfg := config.FromContextOrDefaults(ctx) // ... _, timeoutErr := validateTimeout(ts.Timeout, cfg.Defaults.DefaultTimeoutMinutes) errs = errs.Also(timeoutErr) // ... } // In some resource-agnostic location func validateTimeout(timeout *metav1.Duration, defaultTimeoutMinutes int) (*metav1.Duration, *apis.FieldError) { if timeout == nil { return &metav1.Duration{Duration: time.Duration(defaultTimeoutMinutes) * time.Minute}, nil } if timeout.Duration < 0 { return nil, apis.ErrInvalidValue(timeout.Duration.String()+" should be >= 0", "timeout") } return timeout, nil }

aThorp96 · 2025-06-03T12:11:47Z

config/300-crds/300-pipelinerun.yaml

@@ -4474,6 +4474,11 @@ spec:
                              description: The name of the Step to override.
                              type: string
                        x-kubernetes-list-type: atomic
+                      timeout:
+                        description: |-
+                          Time after which the TaskRun times out.


Suggested change

Time after which the TaskRun times out.

Time after which the TaskRun times out.

Must be less than or equal to `pipelineRun.spec.timeouts.tasks`.

aThorp96 · 2025-06-03T12:16:51Z

pkg/apis/pipeline/v1beta1/taskrun_validation.go

+// validateTaskRunSpecTimeouts validates that the timeout is a valid duration and is not negative.
+func validateTaskRunSpecTimeouts(timeout *metav1.Duration) (errs *apis.FieldError) {
+	if timeout == nil {
+		return nil
+	}
+
+	if timeout.Duration < 0 {
+		return errs.Also(apis.ErrInvalidValue(timeout.Duration.String()+" should be >= 0", "timeout"))
+	}
+
+	return nil
+}


Would it be an antipattern to use the v1 implementation of validateTaskRunSpecTimeouts here?

aThorp96 · 2025-06-03T12:36:01Z

pkg/apis/pipeline/v1/pipelinerun_validation.go

@@ -331,3 +341,33 @@ func validateTaskRunSpec(ctx context.Context, trs PipelineTaskRunSpec) (errs *ap
 	}
 	return errs
 }
+
+// validatePipelineTaskRunSpecTimeouts validates timeouts for TaskRunSpecs in a PipelineRun
+func validatePipelineTaskRunSpecTimeouts(ps *PipelineRunSpec, ctx context.Context) *apis.FieldError {


nit: conventionally the context is usually the first argument

aThorp96 · 2025-06-03T12:54:34Z

pkg/apis/pipeline/v1/pipelinerun_validation.go

+	pipelineTimeout := ps.Timeouts.Pipeline
+	if pipelineTimeout == nil {
+		pipelineTimeout = &metav1.Duration{Duration: time.Duration(config.FromContextOrDefaults(ctx).Defaults.DefaultTimeoutMinutes) * time.Minute}
+	}


What do you think about something like this? This implementation adds a couple things:

Creates a central timeout validation function which falls back to the default if no timeout is supplied, and if the timeout is negative then it of course fails. It DRYs up the validation for both TaskRuns schema versions and could also be used on the PipelineRun.spec.timeouts as well

PipelineRunTask timeout check now ensures that the timeout is 0 < timeout < maxTimeout where maxTimeout is the first present in: pr.spec.timeouts.tasks || pr.spec.timeouts.pipeline || defaultTimeout,

// in the PipelineValidation func validatePipelineTaskRunSpecTimeouts(ps *PipelineRunSpec, ctx context.Context) *apis.FieldError { cfg := config.FromContextOrDefaults(ctx) var errs *apis.FieldError maxTimeout := &metav1.Duration{Duration: time.Duration(cfg.Defaults.DefaultTimeoutMinutes) * time.Minute} if ps.Timeouts != nil { // Loop over max-timeouts in order of precedence to find most applicable for _, timeout := range []*metav1.Duration{ps.Timeouts.Tasks, ps.Timeouts.Pipeline} { if timeout != nil { timeout, err := validateTimeout(ps.Timeouts.Tasks, cfg.Defaults.DefaultTimeoutMinutes) if err != nil { return errs.Also(err) } maxTimeout = timeout break } } } if maxTimeout.Duration == config.NoTimeoutDuration || len(ps.TaskRunSpecs) == 0 { return errs } for _, taskRunSpec := range ps.TaskRunSpecs { taskRunTimeout, err := validateTimeout(taskRunSpec.Timeout, cfg.Defaults.DefaultTimeoutMinutes) if err != nil { errs = errs.Also(err) } else if taskRunTimeout.Duration > maxTimeout.Duration { errs = errs.Also(apis.ErrInvalidValue(fmt.Sprintf("%s should be <= pipeline tasks duration %s", &taskRunTimeout.Duration, maxTimeout.Duration), "taskRunSpecs["+taskRunSpec.PipelineTaskName+"].timeout")) } } return errs } // In the TaskRun validation func (ts *TaskRunSpec) Validate(ctx context.Context) (errs *apis.FieldError) { cfg := config.FromContextOrDefaults(ctx) // ... _, timeoutErr := validateTimeout(ts.Timeout, cfg.Defaults.DefaultTimeoutMinutes) errs = errs.Also(timeoutErr) // ... } // In some resource-agnostic location func validateTimeout(timeout *metav1.Duration, defaultTimeoutMinutes int) (*metav1.Duration, *apis.FieldError) { if timeout == nil { return &metav1.Duration{Duration: time.Duration(defaultTimeoutMinutes) * time.Minute}, nil } if timeout.Duration < 0 { return nil, apis.ErrInvalidValue(timeout.Duration.String()+" should be >= 0", "timeout") } return timeout, nil }

docs: timeout definition per PipelineRun taskRunSpecs cleanup: refactor timeouts validation for pipelineRun taskRunSpecs test: 0s pipeline timeout but long taskrun timeout

tekton-robot · 2025-06-03T13:47:13Z

The following is the coverage report on the affected files.
Say /test pull-tekton-pipeline-go-coverage-df to re-run this coverage report

File	Old Coverage	New Coverage	Delta
pkg/apis/pipeline/v1/pipelinerun_types.go	92.5%	92.5%	0.1
pkg/apis/pipeline/v1/pipelinerun_validation.go	94.7%	94.0%	-0.7
pkg/apis/pipeline/v1/taskrun_validation.go	97.4%	97.5%	0.0
pkg/apis/pipeline/v1beta1/pipelinerun_validation.go	97.2%	97.7%	0.6
pkg/apis/pipeline/v1beta1/taskrun_validation.go	97.4%	98.1%	0.7

l-qing · 2025-06-14T15:34:14Z

Such a useful feature, should we add a release note to recommend it to everyone? 😆

github-project-automation bot added this to Tekton Community Roadmap Mar 11, 2025

github-project-automation bot moved this to Todo in Tekton Community Roadmap Mar 11, 2025

tekton-robot added do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. release-note-none Denotes a PR that doesnt merit a release note. size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Mar 11, 2025

tekton-robot requested review from afrittoli and dibyom March 11, 2025 14:47

tekton-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Mar 11, 2025

waveywaves force-pushed the override-task-timeout branch from 41cbb8b to 1cb87f9 Compare March 11, 2025 15:12

tekton-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Mar 11, 2025

waveywaves force-pushed the override-task-timeout branch from 1cb87f9 to d5ca69c Compare March 28, 2025 23:47

waveywaves force-pushed the override-task-timeout branch from d5ca69c to 0418ce7 Compare March 29, 2025 00:20

waveywaves closed this Mar 29, 2025

waveywaves force-pushed the override-task-timeout branch from 0418ce7 to 5b082b1 Compare March 29, 2025 00:27

github-project-automation bot moved this from Todo to Done in Tekton Community Roadmap Mar 29, 2025

tekton-robot added size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. and removed size/L Denotes a PR that changes 100-499 lines, ignoring generated files. labels Mar 29, 2025

waveywaves reopened this Mar 29, 2025

github-project-automation bot moved this from Done to In Progress in Tekton Community Roadmap Mar 29, 2025

tekton-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. labels Mar 29, 2025

waveywaves marked this pull request as ready for review March 29, 2025 00:31

tekton-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Mar 29, 2025

waveywaves force-pushed the override-task-timeout branch from 38db1f0 to 440d481 Compare March 29, 2025 00:45

waveywaves force-pushed the override-task-timeout branch 2 times, most recently from 9c66620 to ee773fc Compare March 31, 2025 19:52

waveywaves force-pushed the override-task-timeout branch from ee773fc to c19714c Compare March 31, 2025 20:06

vdemeester approved these changes Apr 1, 2025

View reviewed changes

tekton-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Apr 1, 2025

twoGiants reviewed Apr 30, 2025

View reviewed changes

waveywaves force-pushed the override-task-timeout branch 2 times, most recently from 298fd76 to 7e0706d Compare May 7, 2025 12:16

aThorp96 reviewed Jun 3, 2025

View reviewed changes

feat: override task timeouts in pipelineruns

437a2bd

docs: timeout definition per PipelineRun taskRunSpecs cleanup: refactor timeouts validation for pipelineRun taskRunSpecs test: 0s pipeline timeout but long taskrun timeout

waveywaves force-pushed the override-task-timeout branch from 7e0706d to 437a2bd Compare June 3, 2025 13:35

	along with `securityContext` from the `pipelineRun.spec.podTemplate`. The task will also have a specific timeout of 1 hour and 30 minutes. This overrides any existing timeout already defined by the pipelineTask as well.
	along with `securityContext` from the `pipelineRun.spec.podTemplate`. The task will also have a specific timeout of 1 hour and 30 minutes. This overrides any existing timeout already defined by the pipelineTask as well, though the specified `pipelineRun.spec.timeouts.tasks` will still take precedence.

-	// Time after which the TaskRun times out.
+	// Time after which the TaskRun times out. Overrides the timeout specified
+	// on the Task's spec if specified. Takes lower precedence to PipelineRun's
+	// `spec.timeouts.tasks`

	Time after which the TaskRun times out.
	Time after which the TaskRun times out.
	Must be less than or equal to `pipelineRun.spec.timeouts.tasks`.

feat: override task timeouts in pipelineruns #8636

Are you sure you want to change the base?

feat: override task timeouts in pipelineruns #8636

Uh oh!

Conversation

waveywaves commented Mar 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Changes

Submitter Checklist

Release Notes

Uh oh!

waveywaves commented Mar 11, 2025

Uh oh!

tekton-robot commented Mar 11, 2025

Uh oh!

tekton-robot commented Mar 11, 2025

Uh oh!

tekton-robot commented Mar 28, 2025

Uh oh!

tekton-robot commented Mar 29, 2025

Uh oh!

tekton-robot commented Mar 29, 2025

Uh oh!

tekton-robot commented Mar 29, 2025

Uh oh!

tekton-robot commented Mar 31, 2025

Uh oh!

tekton-robot commented Mar 31, 2025

Uh oh!

tekton-robot commented Mar 31, 2025

Uh oh!

waveywaves commented Mar 31, 2025

Uh oh!

vdemeester left a comment

Choose a reason for hiding this comment

Uh oh!

tekton-robot commented Apr 1, 2025

Uh oh!

waveywaves commented Apr 28, 2025

Uh oh!

twoGiants left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

twoGiants Apr 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

twoGiants Apr 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tekton-robot commented May 7, 2025

Uh oh!

tekton-robot commented May 7, 2025

Uh oh!

tekton-robot commented May 7, 2025

Uh oh!

tekton-robot commented May 7, 2025

Uh oh!

tekton-robot commented May 7, 2025

Uh oh!

waveywaves commented Jun 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

waveywaves commented Mar 11, 2025 •

edited

Loading

twoGiants left a comment •

edited

Loading

twoGiants Apr 30, 2025 •

edited

Loading

twoGiants Apr 30, 2025 •

edited

Loading