Design: Deployment build-pipeline-resource

[nader-ziada]

The work for this task is to design this feature and present one or more proposals (before implementing).

Expected Behavior

A common expectation of a pipeline is to deploy the created application/function on some cluster

The deploy resource should satisfy the following requirements:

• Defined as an output of a Task
• Can only be used as an output binding, if used as an input will have no-op
• Can deploy the application/function using a helm chart
• Helm chart is provided to the resource
• Follows the standard resource interface and can be created the same way

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
  ...  

Actual Behavior

We have no resource currently to deploy using helm chart or otherwise

Additional Info

• related to Implement working Task that deploys to k8s using helm #63
• kritis helm docs as an example
• kritis helm charts

[bobcatfish]

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

[afrittoli]

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.

[dibyom]

Don't think this is as relevant anymore given that PipelineResources are not in beta? @sbwsg can we close this?

[ghost]

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.