-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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-0076] Add array support for emitting results #4818
[TEP-0076] Add array support for emitting results #4818
Conversation
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
logger.Fatalf("Error while handling results: %s", err) | ||
} | ||
} | ||
|
||
return err | ||
} | ||
|
||
func (e Entrypointer) readResultsFromDisk() error { | ||
func (e Entrypointer) readResultsFromDisk(resultDir string) error { |
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 for better unit testing. Without this I think we cannot create "tekton/results" dir to emit results
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
/assign ywluogg |
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
@@ -39,7 +39,7 @@ type TaskRunResult struct { | |||
Type ResultsType `json:"type,omitempty"` | |||
|
|||
// Value the given value of the result | |||
Value string `json:"value"` | |||
Value ArrayOrString `json:"value"` |
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 looks like a API change to me. It seems like we need to follow https://github.com/tektoncd/pipeline/blob/main/api_compatibility_policy.md#alpha-beta-and-ga for adding new feature and deprecation rules. Pinging @dibyom for confirmation. This is a field that users can specify. I think we should add a separate field for the new ArrayOrString and implement on the new field
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 is a change, but it won't have effect on users or introduce breaking changes. And our TEP0076 requires us to change this Value
I believe?
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.
We came to a conclusion that this won't be breaking the API change policy. However, we definitely are blocked by the design about whether we want to have a brand new struct on this or just rename StringOrArray.
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.
Ok but it doesn't block this PR right, I'm still using StringOrArray. We need to figure out that in Chuang's
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.
Ok
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 sure!
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.
cc:@ywluogg, I remember you send email to remind the changes, so we should send emails specifically about cli for this?
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 looks like api mismatch between the pipeline and cli, it should be fixed when we release this change and then bump the pipeline version for cli? Am I correct? @pritidesai
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.
/cc @tektoncd/cli-maintainers
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 looks like api mismatch between the pipeline and cli, it should be fixed when we release this change and then bump the pipeline version for cli? Am I correct? @pritidesai
I think It will be fixed when CLI bumps the pipelines version (which will have these changes) and update their usage/implementation to change the type of the results from string
to StringOrArray
. The error reported here is coming from:
./pkg/cmd/taskrun/list.go: return fmt.Errorf("failed to list TaskRuns from namespace %s: %v", p.Namespace(), err)
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
/test pull-tekton-pipeline-build-tests |
2f6547a
to
920c5e5
Compare
The following is the coverage report on the affected files.
|
var err error | ||
if referencedPipelineTask.IsCustomTask() { | ||
runName = referencedPipelineTask.Run.Name | ||
resultValue, err = findRunResultForParam(referencedPipelineTask.Run, resultRef) | ||
runValue, err = findRunResultForParam(referencedPipelineTask.Run, resultRef) | ||
resultValue = *v1beta1.NewArrayOrString(runValue) |
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.
should this be calling unmarshalling here? Calling NewArrayOrString with runValue
here returns a string
.
Also, why limiting this to just the custom 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.
Also, why limiting this to just the custom task?
So custom task results are still string
:
type RunResult struct {
// Name the given name
Name string `json:"name"`
// Value the given value of the result
Value string `json:"value"`
}
Are we planning on changing the custom task result to string/array? Something coming up ...
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, this is a great question! We don't support structured results for custom task in this PR. So this is intentionally to return string here.
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.
We plan to add support for task and pipeline first, custom task is not discussed and also not explicitly mentioned in the tep (in tep we only mention task and pipeline) but we will discuss later!
https://github.com/tektoncd/community/blob/main/teps/0076-array-result-types.md#summary
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.
The first use case explicitly talks about custom task - https://github.com/tektoncd/community/blob/main/teps/0076-array-result-types.md#use-cases Custom task params
has use case to consume an array which could be a result of other task and produce a result with an array (a list of hashes/a list of built images).
Thank you @Yongxuanzhang for following up on this 🙏
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! I have added in our tracking issue
920c5e5
to
a13d9d4
Compare
The following is the coverage report on the affected files.
|
This commit provides support for emitting array results via changing TaskRunResult value from string to ArrayorString and add ResultValue for PipelineResourceResult. Previous to this commit we can only emit string type result.
a13d9d4
to
afacd43
Compare
/test pull-tekton-pipeline-alpha-integration-tests |
The following is the coverage report on the affected files.
|
@Yongxuanzhang thank you for this 🙏 I have updated the release notes. |
Thank you!! ❤️ |
We have opened an issue to track a This change will be part of the GitHub release notes after a release is created. /lgtm |
This commit fixes the string result type validation, PR tektoncd#4779 adds result type and asumes that the default type should be string via mutating webhook. PR tektoncd#4818 adds the validation for this. However, resources that did already exist in etcd didn't get the default. So this commit relaxes this validation.
This commit fixes the string result type validation, PR tektoncd#4779 adds result type and asumes that the default type should be string via mutating webhook. PR tektoncd#4818 adds the validation for this. However, resources that did already exist in etcd didn't get the default. So this commit relaxes this validation.
This commit fixes the string result type validation, PR tektoncd#4779 adds result type and asumes that the default type should be string via mutating webhook. PR tektoncd#4818 adds the validation for this. However, resources that did already exist in etcd didn't get the default. So this commit relaxes the validation for empty result type.
This commit fixes the string result type validation, PR tektoncd#4779 adds result type and asumes that the default type should be string via mutating webhook. PR tektoncd#4818 adds the validation for this. However, resources that did already exist in etcd didn't get the default. So this commit relaxes the validation for empty result type.
This commit fixes the string result type validation, PR #4779 adds result type and asumes that the default type should be string via mutating webhook. PR #4818 adds the validation for this. However, resources that did already exist in etcd didn't get the default. So this commit relaxes the validation for empty result type.
This commit fixes the string result type validation, PR tektoncd#4779 adds result type and asumes that the default type should be string via mutating webhook. PR tektoncd#4818 adds the validation for this. However, resources that did already exist in etcd didn't get the default. So this commit relaxes the validation for empty result type. Signed-off-by: Andrea Frittoli <[email protected]>
This commit fixes the string result type validation, PR #4779 adds result type and asumes that the default type should be string via mutating webhook. PR #4818 adds the validation for this. However, resources that did already exist in etcd didn't get the default. So this commit relaxes the validation for empty result type. Signed-off-by: Andrea Frittoli <[email protected]>
This commit fixes the string result type validation, PR tektoncd#4779 adds result type and asumes that the default type should be string via mutating webhook. PR tektoncd#4818 adds the validation for this. However, resources that did already exist in etcd didn't get the default. So this commit relaxes the validation for empty result type.
This commit fixes the string result type validation, PR #4779 adds result type and asumes that the default type should be string via mutating webhook. PR #4818 adds the validation for this. However, resources that did already exist in etcd didn't get the default. So this commit relaxes the validation for empty result type.
Changes
This is part of work in TEP-0076
This commit provides support for emitting array results. Previous to
this commit we have changed the TaskResults Type to support array. But we can only emit string type result.
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
functionality, content, code)
(if there are no user facing changes, use release note "NONE")
Release Notes