Add pipeline strawman example #319
Conversation
@dlorenc @imjasonh @tejal29 @aaron-prindle and I have been working on a strawman proposal for adding a Pipeline CRD and also for possibly envolving the Build CRD into a slightly more generic Task CRD. This PR demonstrates some paper prototype examples of what it could look like to define pipelines using the CRDs described in the README.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: bobcatfish If they are not already assigned, you can assign the PR to them by writing 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 |
|
/hold not for merging |
| * [Tasks](#tasks) can exist and be invoked completely independently of | ||
| [pipelines](#pipelines); they are highly cohesive and loosely coupled | ||
| * Test results are a first class concept, being able to navigate test results | ||
| easily is powerful (e.g. see failures easily, dig into logs, like sponge) |
There was a problem hiding this comment.
Is Sponge a well-known concept externally? I only see this blog post mentioning it publicly.
There was a problem hiding this comment.
hah! good catch XD
| from is not known to a task, so they can be provided by a Pipeline or by a user invoking a Task directly. | ||
|
|
||
| `Tasks` are basically [knative BuildTemplates](https://github.com/knative/build-templates) | ||
| with additional input types and clearly defined outputs. |
There was a problem hiding this comment.
Should this mention that we expect that Build can eventually transition to Task, or is that something we don't want to commit to so strongly out the gate?
There was a problem hiding this comment.
We can mention that's a possibility anyway
|
|
||
| Here are the Task Types that are defined. | ||
|
|
||
| 1. `build-push`: This task as the name suggests build an image via kaniko and pushes it to registry. |
| * What **sources** the `Pipeline` runs against | ||
| * Which **serviceAccount** to use (provided to all tasks) | ||
| * What **artifact** stores are used (e.g. Docker registries) | ||
| * Where **results** are stored (e.g. in GCS) |
There was a problem hiding this comment.
I think artifacts could also end up in GCS (e.g., jars, debs, maybe generated docs?), in which case we'd need to consider what makes those an "artifact" and not a "result"
There was a problem hiding this comment.
Good point! I've added a note to the working group design doc
|
|
||
| Finally, we have 2 example [Pipelines](../README.md#pipeline) in [./pipelines](./pipelines) | ||
|
|
||
| 1. [Kritis](.pipelines/kritis.yaml): This exmaple demonstrates how to configure a pipeline which runs unit test, build an image, deploys it to test and then run integration tests. |
| # TODO: just guessing how helm works | ||
| - name: deploy | ||
| image: kubernetes-helm | ||
| args: ['deploy', '--path=', '${pathToHelmChart}', '--set image=${image}', '${helmArgs}'] |
There was a problem hiding this comment.
typo (even though it's just for illustration): --path=${pathToHelmChart}
| @@ -0,0 +1,50 @@ | |||
| apiVersion: kan.k8s.io/v1beta1 | |||
There was a problem hiding this comment.
kan.k8s.io -> pipeline.knative.dev ?
There was a problem hiding this comment.
oh yeah we should change that for sure
|
/hold |
|
Moved this to the pipeline repo: tektoncd/pipeline#1 |
This PR is for discussion purposes only, not for merging :)
@dlorenc @imjasonh @tejal29 @aaron-prindle and I have been working on a
strawman proposal for adding a Pipeline CRD and also for possibly
evolving the Build CRD into a slightly more generic Task CRD.
(Note credit for the examples - which make up the bulk of this PR - goes to @tejal29!)
This PR demonstrates some paper prototype examples of what it could look
like to define pipelines using the CRDs described in the README.
Take a look at the README and examples/README for more info!