-
Notifications
You must be signed in to change notification settings - Fork 222
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
base: main
Are you sure you want to change the base?
Conversation
/kind tep |
ac66492
to
c9e04e2
Compare
Before: default results at the authoring time |
API WG - is confusing in the first review, default in a /assign @afrittoli |
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) |
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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: |
There was a problem hiding this comment.
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") |
There was a problem hiding this comment.
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"?
There was a problem hiding this comment.
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"}) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
c9e04e2
to
a07b496
Compare
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: 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 |
/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]>
a07b496
to
f76fefe
Compare
There was a problem hiding this 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.
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: |
There was a problem hiding this comment.
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.
- input: "$(tasks.check-pr-content.results.image-change)" | ||
- input: "$(tasks.check-pr-content.results.image-change || no)" |
There was a problem hiding this comment.
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")" |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
@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. |
API WG - @jerop to check with @vinamra28 |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
/remove-lifecycle stale |
API WG: @vinamra28 any updates on this? |
API WG: Any new updates here @vinamra28? |
Any updates on this? This proposal has existed for long and the default result feature is necessary for our pipelines |
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]