Document how to add custom tasks to TA pipelines #179
Conversation
Signed-off-by: Adam Cmiel <[email protected]>
|
🚀 Preview is available at https://pr-179--konflux-docs.netlify.app |
The "example-task" example wasn't useful and the slack-webhook-notification one isn't a custom task. Kepp the slack-webhook-notification example but repurpose the section to be specifically about Slack notifications. Remove the part about EC issues because it no longer relates to anything in this doc Signed-off-by: Adam Cmiel <[email protected]>
chmeliik
force-pushed
the
custom-tasks
branch
from
2b61263 to
2b3b3a0
Compare
|
🚀 Preview is available at https://pr-179--konflux-docs.netlify.app |
|
/retest |
| * Your Task must *not* return a modified `SOURCE_ARTIFACT`. | ||
| It's ok if the task modifies the source repo as it executes, but the modifications will be discarded. | ||
| The build will use the original, unmodified `SOURCE_ARTIFACT`. |
There was a problem hiding this comment.
nit:
- It is fine to generate the modified source artifact but that shouldn't be used in any future task that needs to be trusted.
- This is true for any artifacts consumed (source or cachi2) by trusted tasks (prefetch or build)
| NOTE: The presence of the Task in `.tekton/**` is enough to make it available for use in your Pipelines without any extra configuration; | ||
| see link:https://pipelinesascode.com/docs/guide/resolver/[Pipelines-as-Code resolver]. |
There was a problem hiding this comment.
Another PR is proposing a different structure (for remote resolvers). Should we address the potential confusion?
There was a problem hiding this comment.
Hmm, interesting. They are different use cases, but we probably do need to differentiate between them somewhere. Or align, if possible 🤔
That PR: defining a complete "remote" Pipeline (will be referenced from other repos)
This PR: adding a custom Task to a non-remote Pipeline
There was a problem hiding this comment.
Yeah. I don't feel like this PR needs to include both local and remote pipelines/tasks, but maybe just an acknowledgement the the other exists as well?
Should we just keep this PR scoped down to creating your own custom tasks? Then there can be a separate location where we talk about using remote tasks? These pages can be located next to each other.
|
|
||
| Implement the task in e.g. `.tekton/tasks/get-buildah-args.yaml`: | ||
|
|
||
| [source,yaml] |
There was a problem hiding this comment.
We have a repository where we can create some sample pipelines/tasks: https://github.com/konflux-ci/pipeline-samples
What do you think about propose this task there instead so that readers won't have to extract it out of the documentation?
There was a problem hiding this comment.
I think I prefer inline examples, but if we want that to be the pattern that works too
| @@ -0,0 +1,146 @@ | |||
| = Adding custom tasks | |||
|
|
|||
| If your pipeline uses xref:advanced-how-tos/using-trusted-artifacts.adoc[Trusted Artifacts], | |||
There was a problem hiding this comment.
We only talk about TA pipelines here. Can we have a section at the top describing the overall process and then two sections later discussing the uniqueness for TA and PVC pipeline tasks?
There was a problem hiding this comment.
That will improve the sidebar too as it will provide more context to what content will be on the page: https://pr-179--konflux-docs.netlify.app/how-tos/configuring/adding-custom-tasks/
| taskRef: | ||
| params: | ||
| - name: name | ||
| value: example-task # metadata.name field of the Task | ||
| - name: bundle | ||
| value: quay.io/tekton-bundle-catalog/example-task-bundle:1.0 | ||
| # For more details on tekton bundles, refer to https://tekton.dev/docs/pipelines/pipelines/#tekton-bundles | ||
| - name: kind | ||
| value: task | ||
| resolver: bundles |
There was a problem hiding this comment.
This information is relevant for remote resolvers (along with the undocumented git resolver). Should we include some information/reference to these?
|
Marking as draft until I have time to rework this |
No description provided.