The work for this task is to design this feature and present one or more proposals (before implementing).
A common expectation of a pipeline is to deploy the created application/function on some cluster
The deploy resource should satisfy the following requirements:
an example definition of a pipeline
kind: Pipeline
...
spec:
tasks:
- name: unit-test-kritis
taskRef:
name: make
inputSourceBindings:
- name: workspace
key: kritis
outputSourceBindings:
- name: deploy-output
key: deploy-to-test-cluster
params:
- name: makeTarget
value: test
and an example of a resource
...
apiVersion: pipeline.knative.dev/v1beta1
kind: Resource
metadata:
name: deploy-to-test-cluster
namespace: default
spec:
name: deploy-to-test-cluster
type: deploy
params:
- name: cluster
value: kritis-cluster
...
We have no resource currently to deploy using helm chart or otherwise
I like it! I think this should be generic enough that we could define different types of deployers, e.g. kubectl as well as helm
In my view a deployment output resource would be the output of a deployment task, so it would contain the metadata which resulted from the deployment, e.g. the release name and version in case of helm and perhaps a cluster resource. This could basically provide a kind of standard interface to tasks / pipelines who wanted to access the deployed "app" and that could work regardless of the deployment technology used in the deployment step.
However I don't think the deployment output resource should take care of the deployment itself, there should be a deployment task. Similar to how the image output resource does not take care of building and pushing an image, it will only receive the metadata of the built image from a kaniko task or some other build task.
Don't think this is as relevant anymore given that PipelineResources are not in beta? @sbwsg can we close this?
Yeah this doesn't look like it's hugely relevant anymore in the face of all the changes that have gone on around resources. If someone does want to revisit this specific idea then they can always reopen.
Most helpful comment
I like it! I think this should be generic enough that we could define different types of deployers, e.g.
kubectlas well ashelm