do not allow negative requeue times #7589

gabemontero · 2024-01-19T21:44:08Z

/kind bug

Changes

Use of the value of 0 for the taskrun/pipeline timeout, which per https://github.com/tektoncd/pipeline/blob/main/docs/pipelineruns.md#configuring-a-failure-timeout for example means timeout is disabled, results in the waitTime passed to the Requeue event to be negative. This had the observed behavior of Requeue'ing immediately, and intense cycles of many reconcilations per second were observed if the TaskRun's/PipelineRun's state did not in fact change. This artificially constrained the peformance of the pipeline controller.

This change makes sure the wait time passed to the Requeue is not negative.

Submitter Checklist

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

[n/a ] 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
[ /] 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.
[ n/a] Release notes contains the string "action required" if the change requires additional action from users switching to the new release

Release Notes

PipelineRuns and TaskRuns that disable timeouts will no longer experience rapid requeue reconciliations

tekton-robot · 2024-01-19T21:53:11Z

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/reconciler/pipelinerun/pipelinerun.go	92.2%	92.3%	0.0
pkg/reconciler/taskrun/taskrun.go	85.2%	84.7%	-0.5

tekton-robot · 2024-01-19T21:54:08Z

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

File	Old Coverage	New Coverage	Delta
pkg/reconciler/pipelinerun/pipelinerun.go	92.2%	92.3%	0.0
pkg/reconciler/taskrun/taskrun.go	85.2%	84.7%	-0.5

tekton-robot · 2024-01-22T15:06:06Z

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

File	Old Coverage	New Coverage	Delta
pkg/reconciler/pipelinerun/pipelinerun.go	92.2%	92.3%	0.0
pkg/reconciler/taskrun/taskrun.go	85.2%	84.7%	-0.5

tekton-robot · 2024-01-22T15:07:53Z

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/reconciler/pipelinerun/pipelinerun.go	92.2%	92.3%	0.0
pkg/reconciler/taskrun/taskrun.go	85.2%	84.7%	-0.5

tekton-robot · 2024-01-22T15:39:28Z

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

File	Old Coverage	New Coverage	Delta
pkg/reconciler/pipelinerun/pipelinerun.go	92.2%	92.3%	0.0
pkg/reconciler/taskrun/taskrun.go	85.2%	84.7%	-0.5

tekton-robot · 2024-01-22T15:42:01Z

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/reconciler/pipelinerun/pipelinerun.go	92.2%	92.3%	0.0
pkg/reconciler/taskrun/taskrun.go	85.2%	84.7%	-0.5

gabemontero · 2024-01-22T18:26:05Z

/assign @vdemeester
/assign @abayer
/assign @afrittoli

@khrm FYI

khrm · 2024-01-23T05:44:16Z

pkg/reconciler/taskrun/taskrun.go

+		timeout = 6 * time.Hour
+	case elapsed < 24*time.Hour:
+		timeout = 24 * time.Hour
+	case elapsed < 48*time.Hour:


We need to document this behavior.

I tend to agree with @khrm, we need to document these times somehow.

Any suggestions as to where to document @khrm @vdemeester ? The timeout feature is certainly discussed in the pipelinerun and taskrun API markdown docs. But I'm not sure if we should clutter API level discussion with some lower level controller implementation detail.

And there is not a current "controller implementation details" markdown. And I'm not sure if this warrants the creation of such a thing.

And do we drop some hint of the pros and cons of disabling timeouts?

Pending responses from you all, in the interim, I'll work on a doc update to the pipelinerun/taskrun api doc, where timeout is discussed. For the moment at least, I'll refrain from any disabling timeouts warnings. Perhaps such warning necessitate broader community agreement.

Thanks.

Another option here @khrm @vdemeester is to just use the configured global default as the wait time, or some fraction of the configured global default, regardless of what the elapsed time is, when the user chooses to disable the timeout. That is probably sufficient here, and would allow existing controls as a means for the user to tweak things.

I'm leaning toward switching to that .... but I'll wait to hear from you all before making the change here.

This lends itself to a cleaner explanation in the existing sections for timeout of the pipelineruns.md and taskruns.md, as I realized, when I started tinkering with a doc change.

Also, if we go this path, I know realized we would probably want to update the release note to advertise this, right?

Thanks.

I believe I need to expand the 0 timeout checks to the other finally related timeouts, make sure there are not negative wait times for those as well

@gabemontero If I understand correctly, as it is an internal / implementation detail thing, and very similar to something like the "global resync period" of the controller, which is not documented anywhere, might not make sense to document it ; at least in API / users docs. I agree with that, so maybe just some comments would make sense initially 🙃. I wish we had more "deep technical doc", but as we don't have them today, I don't want to block the PR on this indeed.

I think you have captured it correctly @vdemeester

That said, any thoughts from anyone on my simplification for the what wait time to use that I noted in #7589 (comment) ?

To some degree these staggered wait times I essentially just grabbed from the air doesn't feel ideal.

Also, with these requeues, if the item requeued with wait gets updated, it get reconciled on the update anyway, correct? So just using a constant value perhaps is just simpler / better, no?

if my explanation is not clear, I can submit the alternative as a separate commit so folks can compare

vdemeester

/lgtm

vdemeester · 2024-01-23T08:48:19Z

pkg/reconciler/taskrun/taskrun.go

+		timeout = 6 * time.Hour
+	case elapsed < 24*time.Hour:
+		timeout = 24 * time.Hour
+	case elapsed < 48*time.Hour:


I tend to agree with @khrm, we need to document these times somehow.

vdemeester · 2024-01-24T09:34:46Z

pkg/reconciler/taskrun/taskrun.go

+		timeout = 6 * time.Hour
+	case elapsed < 24*time.Hour:
+		timeout = 24 * time.Hour
+	case elapsed < 48*time.Hour:


@gabemontero If I understand correctly, as it is an internal / implementation detail thing, and very similar to something like the "global resync period" of the controller, which is not documented anywhere, might not make sense to document it ; at least in API / users docs. I agree with that, so maybe just some comments would make sense initially 🙃. I wish we had more "deep technical doc", but as we don't have them today, I don't want to block the PR on this indeed.

vdemeester · 2024-01-24T12:33:44Z

cc @JeromeJu @chitrangpatel @afrittoli
I think we may want to backport this to a few LTS as well.
/cherry-pick release-v0.56.x
/cherry-pick release-v0.53.x
/cherry-pick release-v0.50.x
/cherry-pick release-v0.47.x

tekton-robot · 2024-01-24T12:33:47Z

@vdemeester: once the present PR merges, I will cherry-pick it on top of release-v0.56.x in a new PR and assign it to you.

In response to this:

cc @JeromeJu @chitrangpatel @afrittoli
I think we may want to backport this to a few LTS as well.
/cherry-pick release-v0.56.x
/cherry-pick release-v0.53.x
/cherry-pick release-v0.50.x
/cherry-pick release-v0.47.x

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.

vdemeester · 2024-01-24T16:41:24Z

Oh it picks just one cherry-pick by comment ?
/cherry-pick release-v0.53.x

vdemeester · 2024-01-24T16:41:29Z

/cherry-pick release-v0.50.x

vdemeester · 2024-01-24T16:41:33Z

/cherry-pick release-v0.47.x

gabemontero · 2024-01-24T18:46:46Z

@vdemeester @khrm I have pushed a separate commit that replaces staggered (but arbitrary) set of wait time based on elapsed time and just uses the configured timeout default as the wait time

If this approach seems more amenable to everyone, I can cleanup, add a blurb in the docs if desired, and squash appropriately.

If the original form is preferred, I'll just drop the commit.

Of if there are any other suggestions for wait time?

Or perhaps we do not requeue with a wait time in the case timeout has been disabled, and just return nil, and wait for updates to pods/taskruns/pipelineruns result in new reconciliations ?

tekton-robot · 2024-01-24T18:49:02Z

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

File	Old Coverage	New Coverage	Delta
pkg/reconciler/pipelinerun/pipelinerun.go	92.2%	92.2%	-0.1
pkg/reconciler/taskrun/taskrun.go	85.2%	85.4%	0.1

tekton-robot · 2024-01-24T18:51:32Z

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/reconciler/pipelinerun/pipelinerun.go	92.2%	92.2%	-0.1
pkg/reconciler/taskrun/taskrun.go	85.2%	85.4%	0.1

tekton-robot · 2024-01-24T20:21:16Z

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

File	Old Coverage	New Coverage	Delta
pkg/reconciler/pipelinerun/pipelinerun.go	92.2%	92.2%	-0.1
pkg/reconciler/taskrun/taskrun.go	85.2%	85.4%	0.1

tekton-robot · 2024-01-24T20:23:00Z

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/reconciler/pipelinerun/pipelinerun.go	92.2%	92.2%	-0.1
pkg/reconciler/taskrun/taskrun.go	85.2%	85.4%	0.1

vdemeester · 2024-01-29T14:20:25Z

@vdemeester @khrm I have pushed a separate commit that replaces staggered (but arbitrary) set of wait time based on elapsed time and just uses the configured timeout default as the wait time

If this approach seems more amenable to everyone, I can cleanup, add a blurb in the docs if desired, and squash appropriately.

If the original form is preferred, I'll just drop the commit.

Of if there are any other suggestions for wait time?

Or perhaps we do not requeue with a wait time in the case timeout has been disabled, and just return nil, and wait for updates to pods/taskruns/pipelineruns result in new reconciliations ?

Make sense to me on the new commit, it makes things simpler and "in the hand of the user". We can always refine this later if need be.

cc @chitrangpatel @JeromeJu

Use of the value of 0 for the taskrun/pipeline timeout, which per https://github.com/tektoncd/pipeline/blob/main/docs/pipelineruns.md#configuring-a-failure-timeout for example means timeout is disabled, results in the waitTime passed to the Requeue event to be negative. This had the observed behavior of Requeue'ing immediately, and intense cycles of many reconcilations per second were observed if the TaskRun's/PipelineRun's state did not in fact change. This artificially constrained the peformance of the pipeline controller. This change makes sure the wait time passed to the Requeue is not negative. rh-pre-commit.version: 2.1.0 rh-pre-commit.check-secrets: ENABLED

gabemontero · 2024-01-29T15:12:13Z

@vdemeester @khrm I have pushed a separate commit that replaces staggered (but arbitrary) set of wait time based on elapsed time and just uses the configured timeout default as the wait time
If this approach seems more amenable to everyone, I can cleanup, add a blurb in the docs if desired, and squash appropriately.
If the original form is preferred, I'll just drop the commit.
Of if there are any other suggestions for wait time?
Or perhaps we do not requeue with a wait time in the case timeout has been disabled, and just return nil, and wait for updates to pods/taskruns/pipelineruns result in new reconciliations ?

Make sense to me on the new commit, it makes things simpler and "in the hand of the user". We can always refine this later if need be.

cc @chitrangpatel @JeromeJu

cool thanks @vdemeester .... I've gone ahead and squahsed the commits and cleaned up commented out code

also, with this simpler approach, the doc update that you and @khrm mentioned earlier seemed easier, less klunky, so I've gone head and included that as well.

PTAL and see if it is appropriate for that section of the API doc. Thanks.

@chitrangpatel @JeromeJu FYI

tekton-robot · 2024-01-29T15:16:31Z

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

File	Old Coverage	New Coverage	Delta
pkg/reconciler/pipelinerun/pipelinerun.go	92.2%	92.2%	-0.1
pkg/reconciler/taskrun/taskrun.go	85.2%	85.4%	0.1

tekton-robot · 2024-01-29T15:18: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/reconciler/pipelinerun/pipelinerun.go	92.2%	92.2%	-0.1
pkg/reconciler/taskrun/taskrun.go	85.2%	85.4%	0.1

khrm

This implementation is better and simpler. I think we can proceed with that. Docs seem to be in the correct place.

gabemontero · 2024-01-29T15:50:44Z

the beta-integration test failure seems like an unrelated flake to me, best as I an tell

gabemontero · 2024-01-29T16:03:13Z

/retest

gabemontero · 2024-01-29T19:59:21Z

CI green ready for follow reviews / possible acceptance of change @JeromeJu @chitrangpatel @afrittoli @vdemeester @khrm

thanks

tekton-robot · 2024-01-31T15:35:26Z

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: JeromeJu, 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~~ [JeromeJu,vdemeester]

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

vdemeester · 2024-02-06T09:00:45Z

/lgtm

vdemeester · 2024-02-06T11:10:30Z

/retest

tekton-robot · 2024-02-06T11:50:12Z

@vdemeester: new pull request created: #7638

In response to this:

cc @JeromeJu @chitrangpatel @afrittoli
I think we may want to backport this to a few LTS as well.
/cherry-pick release-v0.56.x
/cherry-pick release-v0.53.x
/cherry-pick release-v0.50.x
/cherry-pick release-v0.47.x

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.

tekton-robot · 2024-02-06T11:50:48Z

@vdemeester: #7589 failed to apply on top of branch "release-v0.53.x":

Applying: do not allow negative requeue times
Using index info to reconstruct a base tree...
M	docs/pipelineruns.md
M	docs/taskruns.md
M	pkg/reconciler/pipelinerun/pipelinerun.go
M	pkg/reconciler/pipelinerun/pipelinerun_test.go
M	pkg/reconciler/taskrun/taskrun.go
M	pkg/reconciler/taskrun/taskrun_test.go
Falling back to patching base and 3-way merge...
Auto-merging pkg/reconciler/taskrun/taskrun_test.go
Auto-merging pkg/reconciler/taskrun/taskrun.go
Auto-merging pkg/reconciler/pipelinerun/pipelinerun_test.go
Auto-merging pkg/reconciler/pipelinerun/pipelinerun.go
CONFLICT (content): Merge conflict in pkg/reconciler/pipelinerun/pipelinerun.go
Auto-merging docs/taskruns.md
Auto-merging docs/pipelineruns.md
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 do not allow negative requeue times
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

In response to this:

cc @JeromeJu @chitrangpatel @afrittoli
I think we may want to backport this to a few LTS as well.
/cherry-pick release-v0.56.x
/cherry-pick release-v0.53.x
/cherry-pick release-v0.50.x
/cherry-pick release-v0.47.x

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.

tekton-robot · 2024-02-06T11:51:41Z

@vdemeester: #7589 failed to apply on top of branch "release-v0.50.x":

Applying: do not allow negative requeue times
Using index info to reconstruct a base tree...
M	docs/pipelineruns.md
M	docs/taskruns.md
M	pkg/reconciler/pipelinerun/pipelinerun.go
M	pkg/reconciler/pipelinerun/pipelinerun_test.go
M	pkg/reconciler/taskrun/taskrun.go
M	pkg/reconciler/taskrun/taskrun_test.go
Falling back to patching base and 3-way merge...
Auto-merging pkg/reconciler/taskrun/taskrun_test.go
Auto-merging pkg/reconciler/taskrun/taskrun.go
Auto-merging pkg/reconciler/pipelinerun/pipelinerun_test.go
Auto-merging pkg/reconciler/pipelinerun/pipelinerun.go
CONFLICT (content): Merge conflict in pkg/reconciler/pipelinerun/pipelinerun.go
Auto-merging docs/taskruns.md
Auto-merging docs/pipelineruns.md
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 do not allow negative requeue times
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

In response to this:

cc @JeromeJu @chitrangpatel @afrittoli
I think we may want to backport this to a few LTS as well.
/cherry-pick release-v0.56.x
/cherry-pick release-v0.53.x
/cherry-pick release-v0.50.x
/cherry-pick release-v0.47.x

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.

tekton-robot · 2024-02-06T11:52:23Z

@vdemeester: #7589 failed to apply on top of branch "release-v0.47.x":

Applying: do not allow negative requeue times
Using index info to reconstruct a base tree...
M	docs/pipelineruns.md
M	docs/taskruns.md
M	pkg/reconciler/pipelinerun/pipelinerun.go
M	pkg/reconciler/pipelinerun/pipelinerun_test.go
M	pkg/reconciler/taskrun/taskrun.go
M	pkg/reconciler/taskrun/taskrun_test.go
Falling back to patching base and 3-way merge...
Auto-merging pkg/reconciler/taskrun/taskrun_test.go
Auto-merging pkg/reconciler/taskrun/taskrun.go
Auto-merging pkg/reconciler/pipelinerun/pipelinerun_test.go
CONFLICT (content): Merge conflict in pkg/reconciler/pipelinerun/pipelinerun_test.go
Auto-merging pkg/reconciler/pipelinerun/pipelinerun.go
CONFLICT (content): Merge conflict in pkg/reconciler/pipelinerun/pipelinerun.go
Auto-merging docs/taskruns.md
Auto-merging docs/pipelineruns.md
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch=diff' to see the failed patch
Patch failed at 0001 do not allow negative requeue times
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".

In response to this:

cc @JeromeJu @chitrangpatel @afrittoli
I think we may want to backport this to a few LTS as well.
/cherry-pick release-v0.56.x
/cherry-pick release-v0.53.x
/cherry-pick release-v0.50.x
/cherry-pick release-v0.47.x

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.

tekton-robot added release-note Denotes a PR that will be considered when it comes time to generate release notes. kind/bug Categorizes issue or PR as related to a bug. labels Jan 19, 2024

tekton-robot requested review from bobcatfish and pritidesai January 19, 2024 21:44

tekton-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Jan 19, 2024

gabemontero force-pushed the fix-neg-requeue-wait branch from 3397aa3 to c21d3fa Compare January 22, 2024 14:58

gabemontero force-pushed the fix-neg-requeue-wait branch from c21d3fa to b6664ab Compare January 22, 2024 15:33

tekton-robot assigned afrittoli and vdemeester Jan 22, 2024

khrm reviewed Jan 23, 2024

View reviewed changes

vdemeester reviewed Jan 23, 2024

View reviewed changes

tekton-robot added the lgtm Indicates that a PR is ready to be merged. label Jan 23, 2024

vdemeester approved these changes Jan 24, 2024

View reviewed changes

tekton-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Jan 24, 2024

vdemeester added approved Indicates a PR has been approved by an approver from all required OWNERS files. and removed approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged. labels Jan 24, 2024

gabemontero force-pushed the fix-neg-requeue-wait branch from 11dea3d to 8efbdda Compare January 24, 2024 20:13

JeromeJu self-assigned this Jan 29, 2024

gabemontero force-pushed the fix-neg-requeue-wait branch from 8efbdda to 310041f Compare January 29, 2024 15:09

khrm reviewed Jan 29, 2024

View reviewed changes

JeromeJu approved these changes Jan 31, 2024

View reviewed changes

tekton-robot added the lgtm Indicates that a PR is ready to be merged. label Feb 6, 2024

tekton-robot merged commit 856fb4f into tektoncd:main Feb 6, 2024
12 checks passed

tekton-robot mentioned this pull request Feb 6, 2024

[release-v0.56.x] do not allow negative requeue times #7638

Merged

gabemontero deleted the fix-neg-requeue-wait branch February 6, 2024 17:08

do not allow negative requeue times #7589

do not allow negative requeue times #7589

Conversation

gabemontero commented Jan 19, 2024

Changes

Submitter Checklist

Release Notes

tekton-robot commented Jan 19, 2024

tekton-robot commented Jan 19, 2024

tekton-robot commented Jan 22, 2024

tekton-robot commented Jan 22, 2024

tekton-robot commented Jan 22, 2024

tekton-robot commented Jan 22, 2024

gabemontero commented Jan 22, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gabemontero Jan 23, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vdemeester left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

vdemeester commented Jan 24, 2024

tekton-robot commented Jan 24, 2024

vdemeester commented Jan 24, 2024

vdemeester commented Jan 24, 2024

vdemeester commented Jan 24, 2024

gabemontero commented Jan 24, 2024

tekton-robot commented Jan 24, 2024

tekton-robot commented Jan 24, 2024

tekton-robot commented Jan 24, 2024

tekton-robot commented Jan 24, 2024

vdemeester commented Jan 29, 2024

gabemontero commented Jan 29, 2024

tekton-robot commented Jan 29, 2024

tekton-robot commented Jan 29, 2024

khrm left a comment

Choose a reason for hiding this comment

gabemontero commented Jan 29, 2024

gabemontero commented Jan 29, 2024

gabemontero commented Jan 29, 2024

tekton-robot commented Jan 31, 2024

vdemeester commented Feb 6, 2024

vdemeester commented Feb 6, 2024

tekton-robot commented Feb 6, 2024

tekton-robot commented Feb 6, 2024

tekton-robot commented Feb 6, 2024

tekton-robot commented Feb 6, 2024

gabemontero Jan 23, 2024 •

edited

Loading