-
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
Changes from all commits
f1bd35f
f2054fa
bd3d292
d0671a8
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -185,6 +185,46 @@ See [the example PipelineRun](../examples/invocations/kritis-pipeline-run.yaml). | |
that the `Task` needs to run. | ||
2. The `TaskRun` will also serve as a record of the history of the invocations of the | ||
`Task`. | ||
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 | ||
kind: PipelineResource | ||
metadata: | ||
name: go-example-git | ||
spec: | ||
type: git | ||
params: | ||
- name: url | ||
value: https://github.com/pivotal-nader-ziada/gohelloworld | ||
--- | ||
apiVersion: pipeline.knative.dev/v1alpha1 | ||
kind: TaskRun | ||
metadata: | ||
name: build-push-task-run-2 | ||
spec: | ||
trigger: | ||
triggerRef: | ||
type: manual | ||
inputs: | ||
resources: | ||
- name: workspace | ||
resourceRef: | ||
name: go-example-git | ||
taskSpec: | ||
inputs: | ||
resources: | ||
- name: workspace | ||
type: git | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This type is specified twice, once in the type of the There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 |
||
steps: | ||
- name: build-and-push | ||
image: gcr.io/kaniko-project/executor | ||
command: | ||
- /kaniko/executor | ||
args: | ||
- --destination=gcr.io/my-project/gohelloworld | ||
``` | ||
If the TaskSpec is provided, TaskRef is not allowed. | ||
|
||
See [the example TaskRun](../examples/invocations/run-kritis-test.yaml). | ||
|
||
|
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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.
One option @pivotal-nader-ziada and I talked about was embedding the
Resource
spec inside theresource
field in theTaskRun
, e.g.: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.
That's a good point!
Sounds good to me