-
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
Custom task without api version return validation error #6505
Conversation
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
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'll need to modify the isCustomTask
functions introduced in #6447.
Also (nit) there are some typos in the PR title/description where custom is spelled "custome", please fix.
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
|
||
notCustomTaskKinds := map[TaskKind]bool{ | ||
"": true, | ||
NamespacedTaskKind: true, |
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.
@jerop can you take a look here? I'm not sure if validation runs before or after defaulting. If the user sets "kind" = Task, didn't we decide that should be a 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.
if user sets kind to task:
- if apiversion is non-empty --> custom task
- if apiversion is empty --> task (because this is what we default to, we add kind but leave apiversion as empty)
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.
Do you or @Yongxuanzhang know whether defaulting runs before or after validation? (I couldn't find the answer here or here). If validation runs before defaulting, using kind = "Task" would be treated here as a Task when it's actually a custom task. But if defaulting runs first, using kind = "Task" is correctly treated here as a Task. My guess is the logic is correct since e2e tests are passing, but want to double check.
@@ -123,6 +123,27 @@ func TestPipeline_Validate_Failure(t *testing.T) { | |||
Message: `expected at least one, got none`, | |||
Paths: []string{"spec.description", "spec.params", "spec.resources", "spec.tasks", "spec.workspaces"}, | |||
}, | |||
}, { |
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.
@Yongxuanzhang please add test cases where kind is set to:
- "Task"
- ClusterTask"
- ""
Then add 3 more test cases that are exactly like above, but then APIVersion is also set
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.
please update the docs and add release notes 🙏🏾
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
case pt.TaskRef != nil && !notCustomTaskKinds[pt.TaskRef.Kind]: | ||
errs = errs.Also(pt.validateCustomTask()) | ||
case pt.TaskRef != nil && pt.TaskRef.APIVersion != "": |
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 might be more readable as:
case pt.TaskRef != nil:
if pt.TaskRef.APIVersion != "" || !notCustomTaskKinds[pt.TaskRef.Kind] {
pt.validateCustomTask()
}
(Also could the double negative !notCustomTaskKinds be made into a positive?)
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 not so easy to merge these 2, there are some cases in this switch control, it seems not add readability with this
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
/retest |
taskKinds := map[TaskKind]bool{ | ||
"": true, | ||
NamespacedTaskKind: true, | ||
"ClusterTask": true, |
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 don't have cluster tasks in v1
"ClusterTask": true, |
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 this section of our docs is wrong: https://github.com/tektoncd/pipeline/blob/main/docs/tasks.md#task-vs-clustertask ("There is no v1 API specification for ClusterTask but a v1beta1 clustertask can still be referenced in a v1 pipeline.")
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 this might not have been correct: #6587
p: &Pipeline{ | ||
ObjectMeta: metav1.ObjectMeta{Name: "pipeline"}, | ||
Spec: PipelineSpec{ | ||
Tasks: []PipelineTask{{Name: "foo", TaskRef: &TaskRef{Kind: "Example", Name: ""}}}, |
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.
what happens if there was apiversion but no kind?
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 tested in another test (pipelinetask validate), I will move these cases there.
Spec: PipelineSpec{ | ||
Tasks: []PipelineTask{{Name: "foo", TaskSpec: &EmbeddedTask{ | ||
TypeMeta: runtime.TypeMeta{ | ||
Kind: "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.
what happens if there was apiversion but no kind?
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.
please add docs and release notes
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.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lbernick 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:
Approvers can indicate their approval by writing |
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.
/lgtm
This commit closes tektoncd#6459. For a customtask reference in a pipelinetask, if the Kind is non-empty and not "Task" or "ClusterTask", then it should be a Custom task and api version should be set. If not then validation webhook should return error. TaskRun's taskRef validation will be handled separately in tektoncd#6557 Signed-off-by: Yongxuan Zhang yongxuanzhang@google.com
The following is the coverage report on the affected files.
|
The following is the coverage report on the affected files.
|
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.
/lgtm
Changes
This commit closes #6459. For a customtask reference in a pipelinetask, if the Kind is non-empty and not "Task" or "ClusterTask", then it should be a Custom task and api version should be set. If not then validation webhook should return error. TaskRun's taskRef validation will be handled separately in #6557
/kind bug
Signed-off-by: Yongxuan Zhang yongxuanzhang@google.com
Submitter Checklist
As the author of this PR, please check off the items in this checklist:
/kind <type>
. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tepRelease Notes