-
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
Run taskRun without a Task by adding TaskSpec #262
Conversation
1495fbe
to
0959c36
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.
One comment, otherwise looks good 👼
} | ||
return validateTaskRunAndTask(c, *tr, t, tr.Namespace) | ||
return nil |
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.
Shouldn't we validate it in that case too ? 🤔
This would require to change the signature of validateTaskRunTask
though, but most likely for the good
// […]
return validateTaskRunAndTask(c, *tr, t.Spec, tr.Namespace)
}
return validateTaskRunAndTask(c, *tr, tr.TaskSpec, tr.Namespace)
(On that note, thinking outloud, we only validate the spec, so we may want to pass only the specs — the tr.Name
is only required on the error message, so we could use github.com/pkg/errors
to wrap errors and thus adding the tr.Name
via the caller)
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.
good point, I should add that
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 would recommend updating taskrun test(kaniko) or pipelinerun e2e test to include a taskrun which has inlined taskspec. WDYT @pivotal-nader-ziada ?
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.
Some comments from pair review with @pivotal-nader-ziada :
- leaning toward not supporting
sources
in this initial PR - need some docs on how to use this
Name: "myarg", | ||
Description: "mydesc", | ||
Default: "mydefault", | ||
}}, |
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.
looks like maybe we DO support params! i cant see a strong reason not support them esp. if we get it for free
0959c36
to
17de7e2
Compare
@bobcatfish addressed the comments, ready for another look |
17de7e2
to
bfc4806
Compare
taskSpec = taskRun.Spec.TaskSpec | ||
taskName = taskRun.Name | ||
} else { | ||
return taskSpec, taskName, fmt.Errorf("TaskRun %s not providing TaskRef or TaskSpec", taskRun.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.
this happens to be the only line not covered by the unit tests and i actually wonder if we need it at all - at this point, we do happen to know that the taskSpec has been validated, and there should be no case like this
however maybe its safer to keep it - im fine with not covering the line in unit tests :D
Looks great to me! Thanks for adding the docs also ^.^ /lgtm I'm going to add a hold here b/c @imjasonh opened the issue and might have some opinions about us removing /hold /meow space |
In response to this:
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. |
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
3. Another way of running a Task is embedding the TaskSpec in the taskRun yaml as shown in the following example | ||
|
||
```yaml | ||
apiVersion: pipeline.knative.dev/v1alpha1 |
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.
So we still need to create two resources to run a simple set of steps? How can we drop the requirement that a PipelineResource already exists?
In Build, resources were specified directly in the build itself, as source(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.
yes, we felt this would be an acceptable compromise so its not too different from the rest of the pipeline project and confusing for users
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.
How can we drop the requirement that a PipelineResource already exists?
One option @pivotal-nader-ziada and I talked about was embedding the Resource
spec inside the resource
field in the TaskRun
, e.g.:
inputs:
resources:
- name: workspace
resourceSpec:
type: git
params:
- name: url
value: https://github.com/pivotal-nader-ziada/gohelloworld
This is kinda the direction @shashwathi is going in #270 as well, where we can use the TaskRunResource
to provide a path where the resource will be located in a PVC.
We'd need to actually create an instance of the Resource
probably, so we can extend Resources generically (#238)
@imjasonh would you like to see something like that in this PR or a follow up PR?
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 adding even more embedding is just making the yaml file too complicated. Also one side benefit is that the resources are such a core concept in build-pipeline that we want users to know about when migrating.
Maybe as part of the work for the resources extensibility we can make this easier by making the taskRun controller create the resource for for system supported resource types such as git. In that case, the we can define types for system resources with their specific fields to simplify yaml files for all tasks
Depending on what we decide here, how big the change is, it might be better to have another follow up PR so this one doesn't get too big
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 adding even more embedding is just making the yaml file too complicated. Also one side benefit is that the resources are such a core concept in build-pipeline that we want users to know about when migrating.
That's a good point!
Depending on what we decide here, how big the change is, it might be better to have another follow up PR so this one doesn't get too big
Sounds good to me
inputs: | ||
resources: | ||
- name: workspace | ||
type: git |
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 type is specified twice, once in the type of the workspace
resource (line 194) and again here. Can one be removed? What happens if the resource is type:foo
but I specify it as an input with type: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.
the runtime validation in the controller would give an error about the resource type. The reason its defined twice is that its usually in two different objects, task and taskRun, and we were trying to use the existing code and types
// can't have both taskRef and taskSpec at the same time | ||
if (ts.TaskRef != nil && ts.TaskRef.Name != "") && ts.TaskSpec != nil { | ||
fields := []string{"spec.taskref", "spec.taskspec"} | ||
return apis.ErrDisallowedFields(fields...) |
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 should work:
return apis.ErrDisallowedFields("spec.taskref", "spec.taskspec")
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, I can change that one
|
||
// Check that one of TaskRef and TaskSpec is present | ||
if (ts.TaskRef == nil || (ts.TaskRef != nil && ts.TaskRef.Name == "")) && ts.TaskSpec == nil { | ||
fields := []string{"spec.taskref.name", "spec.taskspec"} |
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.
Here too
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.
will also change it
bfc4806
to
41d2531
Compare
41d2531
to
2a2733c
Compare
/hold cancel since I made a small fix and rebased which removed the lgtm |
/lgtm Sounds like there are some more streaming changes we should make, but those definitely don't belong in this PR. Thanks for doing this work Nader, this should definitely improve the basic getting-started experience, and will make Serving usage simpler, once we get there. |
- users can specifiy TaskRef or TaskSpec, but not both - update type - add validation and tests - update taskRef everywhere to be a pointer since its now optional Signed-off-by: Nader Ziada <[email protected]>
- remove support for using sources in the taskSpec - use TaskResolver - refactor tests Signed-off-by: Nader Ziada <[email protected]>
Signed-off-by: Nader Ziada <[email protected]>
2a2733c
to
d0671a8
Compare
The following is the coverage report on pkg/.
|
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
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: pivotal-nader-ziada, vdemeester 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 |
This makes it safe to remove triggers from a cluster without impacting the shared pipelines namespace. Fixes tektoncd#262.
Fixes #249
Proposed Changes
TaskRun
which is mutually exclusive with taskRefTaskRun
without a taskif TaskSpec includessources
it doesn't need to be defined as aResource
now with this feature, users can run
TaskRun
without a task as demonstrated by the following example: