Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[TEP-0048] Task Results without Results #954

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

vinamra28
Copy link
Member

This TEP is updated with the new proposed solution where we now specify the default value for results at the time where they are consumed.

/kind feature

Signed-off-by: vinamra28 [email protected]

@tekton-robot tekton-robot added the kind/feature Categorizes issue or PR as related to a new feature. label Feb 13, 2023
@tekton-robot tekton-robot added the size/L Denotes a PR that changes 100-499 lines, ignoring generated files. label Feb 13, 2023
@vinamra28
Copy link
Member Author

/kind tep

@tekton-robot tekton-robot added the kind/tep Categorizes issue or PR as related to a TEP (or needs a TEP). label Feb 13, 2023
@pritidesai
Copy link
Member

Before: default results at the authoring time
Now: default results at the time of resolution

@pritidesai
Copy link
Member

API WG - is confusing in the first review, default in a pipelineTask instead of task authoring time
Alternative 1 - instead of default value during the resolution, specify default explicitly.

/assign @afrittoli
/assign @lbernick

@jerop
Copy link
Member

jerop commented Feb 13, 2023

noting that this was first suggested and discussed in #240 (comment) by @bobcatfish and @chhsia0

a user @kyubisation - also asked for this feature - tektoncd/pipeline#6139 (comment)

teps/0048-task-results-without-results.md Outdated Show resolved Hide resolved
teps/0048-task-results-without-results.md Outdated Show resolved Hide resolved
if the `Task` fails to produce it. If a `Task` does not produce a `Result` that does not
have a default value, then the `Task` should fail - see [tektoncd/pipeline#3497](https://github.com/tektoncd/pipeline/issues/3497) for further details.
If the `Task` doesn't produces any result then it should fail. In order to
continue with the execution of `Pipeline`, `onError: continue` should be added
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought onError was only available in a task spec? can you give an example?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure whether TEP-0050 is 100% implemented or not but saw it there cc @jerop

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's still "implementable" instead of "implemented" so maybe it wasn't completed? cc @QuanZhang-William

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this is correct. I didn't get a chance to implement this feature. I also did a PR search in the pipeline and didn't find much related.

metadata:
name: pipeline-with-defaults
spec:
tasks:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It might be helpful to make this example more realistic based on this TEP's use cases; it would help show why the Pipeline is the appropriate level for defaults rather than the task

name: demo-task
params:
- name: param1
value: $(tasks.taskA.results.merge_status || "foobar")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is interesting; it seems like there are two ways to specify the default. Here, taskA's result defaults to "squash", so is there ever a case where it could be "foobar"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ahh sorry, I missed removing the default: squash (this is part of alternative solution 1)

- name: param2
value: $(tasks.taskA.results.branches || [foo, bar, baz])
- name: param3
value: $(tasks.taskA.results.images || {node="foo", gcloud="bar"})
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you also do this for Pipeline results?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, @vinamra28 let's add an examples in pipeline results

@@ -631,6 +663,7 @@ spec:
description: The pullRequestNumber
tasks:
- name: check-name-match
onError: continue
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this valid? I don't see it in the api

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

replied in comment #954 (comment)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not available yet at task level, only at step level.

teps/0048-task-results-without-results.md Outdated Show resolved Hide resolved
@@ -670,6 +707,103 @@ Having default results defined in check-name-matches Task will fix the Pipeline.

## Alternatives

### Specifying Default Value during Runtime
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why was this alternative rejected?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if was explicitly rejected - I don't see it as orthogonal to the chosen one - but perhaps it would be best to clarify whether these alternatives are meant as not going to be implemented or possibly going to be implemented later?

@tekton-robot
Copy link
Contributor

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please ask for approval from afrittoli after the PR has been reviewed.

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

Needs approval from an approver in each of these files:

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

@Yongxuanzhang
Copy link
Member

/assign

This TEP is updated with the new proposed solution where we now specify
the default value for results at the time where they are consumed.

Signed-off-by: vinamra28 <[email protected]>
@tekton-robot
Copy link
Contributor

The following Tekton test failed:

Test name Commit Details Required Rerun command
pull-community-teps-lint f76fefe link true /test pull-community-teps-lint

Copy link
Member

@afrittoli afrittoli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks! This looks mostly good, I have a couple of comments though.
I'm not entirely sure we should prioritise the variable option vs. the pipeline task one.

Comment on lines +432 to +433
We propose adding default value at the place where variable replacement
happens and let consumer decide which value it wants to pick up. For example:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can image use cases for both task authoring time and pipeline authoring time, I'm not sure one should exclude the other - but it'd be ok to prioritise one implementation against the other.

In terms of pipeline authoring time, the result default value could also be defined as part of the pipeline task.
Having it in the variable replacement means that, if the result is consumed more than once, the default will have to be repeated everywhere. It seems unlikely to me that a pipeline author would have different result default values for different consumers. But again, I can imagine us implementing both options eventually.

Comment on lines -494 to +526
- input: "$(tasks.check-pr-content.results.image-change)"
- input: "$(tasks.check-pr-content.results.image-change || no)"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I understand this, but it doesn't look very useful.
I think default results will be useful to execute tasks which depend on tasks which are controlled by a when expression, rather than the when expression directly. There is no reason why the "Check PR content" result should be missing. Instead, if the build-image is not executed, following tasks may won't a default value for the image to be used.

@@ -554,9 +586,9 @@ spec:
runAfter: [ "build-image" ]
params:
- name: trusted-image-name
value: "$(tasks.build-trusted.results.image)"
value: "$(tasks.build-trusted.results.image || "trusted")"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT: I think the strings "trusted" and "untrusted" here are a bit confusing, and don't really help convey how the default value would be useful. Maybe something like "my-image:latest-trusted" and "my-image:latest-untrusted" would be more indicative of the purpose?

@@ -631,6 +663,7 @@ spec:
description: The pullRequestNumber
tasks:
- name: check-name-match
onError: continue
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is not available yet at task level, only at step level.

@@ -670,6 +707,103 @@ Having default results defined in check-name-matches Task will fix the Pipeline.

## Alternatives

### Specifying Default Value during Runtime
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if was explicitly rejected - I don't see it as orthogonal to the chosen one - but perhaps it would be best to clarify whether these alternatives are meant as not going to be implemented or possibly going to be implemented later?

`Task` itself, if `Task` declares a `Result` then it should be considered as
the final value for that result.

### Specifying Default Value at the time of Authoring the Task
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there is another alternative, which would be to define the value at the time of authoring the pipeline, but as part of the pipeline task as opposed to when the result is consumed via a variable.

@tekton-robot tekton-robot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label Mar 30, 2023
@tekton-robot
Copy link
Contributor

@vinamra28: PR needs rebase.

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.

@pritidesai
Copy link
Member

API WG - @jerop to check with @vinamra28

@tekton-robot
Copy link
Contributor

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 tekton-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Aug 13, 2023
@vinamra28
Copy link
Member Author

/remove-lifecycle stale
apologies for leaving this in between 😅 , will take this up and try to get this done

@tekton-robot tekton-robot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Aug 19, 2023
@chitrangpatel
Copy link
Contributor

API WG: @vinamra28 any updates on this?

@chitrangpatel
Copy link
Contributor

API WG: Any new updates here @vinamra28?

@jameshwc
Copy link

jameshwc commented Oct 2, 2024

Any updates on this? This proposal has existed for long and the default result feature is necessary for our pipelines

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. kind/tep Categorizes issue or PR as related to a TEP (or needs a TEP). needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants