-
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
Separate v1beta1.TaskObject to Task and ClusterTask in TaskRun Reconciler #6452
Conversation
Skipping CI for Draft Pull Request. |
[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 |
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
return | ||
} | ||
|
||
if d := cmp.Diff(resolvedTask, tc.expected); d != "" { |
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.
Could you please help me to understand why the nil pointers here are not asserted equal with nil tc.expected here even with the cmpopts.EquateEmpty
?
cc @Yongxuanzhang
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 previous test cases are all comparing with nil, so I think it should work?
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.
Yep I also thought the same. but was stuck here for a bit :/
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.
need to change the expected from runtime.Object
to *v1beta1.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.
Could we check if it makes sense to cast the expected nil as (*v1beta1.Task)(nil) while keeping the expected as runtime.Object
for being more generic in the test case struct?
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 we could just use *v1beta1.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.
Taking a second look on this, I personally feel that maybe we should keep runtime.Object
since tc.expected could also be a ClusterTaskKind even though that we do not necessarily need it since trustedResources won't verify ClusterTask. 🤔 please feel free to help correct if I'm mistaken
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 changed VerifyTask's in this PR to pass task not taskobject, so in tests we should test 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.
Thanks for the pointer! updated.
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 test coverage drop was resulted from separating the TaskObject, while since ClusterTask won't get verified as trustedResources, it would not be necessary to restore it with new ClusterTask test case? |
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.
|
// v1beta1.TaskObject. | ||
func resolveTask(ctx context.Context, resolver remote.Resolver, name string, kind v1beta1.TaskKind, k8s kubernetes.Interface) (v1beta1.TaskObject, *v1beta1.ConfigSource, error) { | ||
// v1beta1.Task or v1beta1.ClusterTask | ||
func resolveTask(ctx context.Context, resolver remote.Resolver, name string, kind v1beta1.TaskKind, k8s kubernetes.Interface) (*v1beta1.Task, *v1beta1.ClusterTask, *v1beta1.ConfigSource, 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.
instead of returning a task and a clusterTask, could we instead convert a clusterTask definition into a Task and just return 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.
yeah I also wanted to do so but I am not sure if there is a way to convert it back to a ClusterTask as specified at
return resolveTask(ctx, resolver, name, kind, k8s) |
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 do we need to convert back into a clustertask?
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 for the case of a remote-cluster-task, https://github.com/tektoncd/pipeline/blob/main/pkg/reconciler/taskrun/resources/taskref_test.go#L376-L407 the resolveTask and the upstream of its caller GetTaskFunc shall return a ClusterTask at the end?
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.
Not sure about those tests, but we just need to fetch the task definition from the cluster, store the task spec in the taskrun status, and execute it. we don't need to keep track of the fact that it's a clustertask. If you take a look at resolveTask
, only the name and task spec (not the task kind) are used from the results of getTask
.
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 @lbernick , I updated the alternative at #6471, would be happy to close the current PR if #6471 is clearer.
One concern was that I am not fully sure when we swap all v1beta1 to v1, if it is still ideal handling ClusterTask? Would be more explicit having one more return value in the getTaskFunc while we are also converting it to v1.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.
We can probably convert a v1beta1 ClusterTask spec to a v1 TaskSpec, so I'm not concerned about the proposed solution after swapping to v1.
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
…iler This commit separates v1beta1.TaskObject to Task and ClusterTask to get prepared for v1 storage swap.
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
closing #6471 as the alternative that is cleaner than the current PR |
Changes
This commit is WIP.
This commit separates v1beta1.TaskObject to Task and ClusterTask to get prepared for v1 storage swap.
part of #5979
/kind misc
I wish I did have a nicer way of breaking up v1beta1.TaskObject instead of returning one of the two CRDs. Any suggestions would be much appreciated
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
functionality, content, code)
/kind <type>
. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tepRelease Notes