-
Notifications
You must be signed in to change notification settings - Fork 123
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
Should the compiler generate Pipeline or PipelineRun #59
Comments
Issue-Label Bot is automatically applying the labels:
Please mark this comment with 👍 or 👎 to give our bot feedback! |
For comparison, every workflow in Argo is like a PipelineRun. Therefore, when we upload a pipeline in kfp, it's treated as a template and stored in object storage instead of applying the template to Kubernetes. |
True. But for Kubeflow Pipelines with Argo there is the KFP UI which allows users to interact with pipelines and provide parameters and see logs, etc. For Tekton we have to rely on |
we could also introduce a |
I will add a flag for development purpose and we should push the cli team to support workspaces. |
Great, I think we should support generate-pipelinerun feature, it's convenient for user to run the whole workflow directly, but not just leave several templates there, also, pipelinerun has several fields which could be defined in there, including pipeline timeout. |
generating pipelinerun might also be useful for adding pod-template such as node selector and affinity features https://github.com/tektoncd/pipeline/blob/master/docs/pipelineruns.md#pod-template |
Personally, I think we should generate tekton pipelinerun by default to align with argo workflow but not pipeline. |
Given more preference towards pipelinerun, lets go with that |
|
Eventually you could have a flag that let you decide whether to embed the pipeline in the pipelinerun or not. |
Whether you want to use Pipeline or PipelineRun depends on what kind of experience you want to give to end-users. Tekton separates static definitions from runtimes and it provides a component called “triggers” that allow you to create runtime objects with several presets. Today “triggers” only respond to HTTPs requests, but I can imagine a future were it will be possible to run “triggers” in different ways. |
/kind discussion |
/remove-kind question |
Related issues:
|
Shouldn't this be closed, considering issue #143 has been closed with PR #166? |
Thanks @Udiknedormin |
@Tomcli: Closing this issue. 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. |
This is a general discussion, not a work item.
Conceptually a
Pipeline
is a static specification orchestrating how a set ofTask
s should be executed. APipelineRun
is an instantiation of a pipeline. A pipeline is a re-usable artifact that can be "run" repeatedly, a pipeline-run is one-and-done.Currently the KFP-Tekton compiler generates a YAML with (multiple)
Tasks
(s) and onePipeline
document. There are however certain features supported by the KFP DSL which are not easily transferred into an equivalent feature in TektonPipelines
, but instead require the concept of aPipelineRun
, like mounting PVC volume to a pipeline workspace or setting a timeout at the pipeline level.Linked issues
pipelineSpec
andtaskSpec
Generate PipelineRun with embedded pipelineSpec and taskSpec #143The text was updated successfully, but these errors were encountered: