Allow resourceSpec within Pipeline definitions

[adrianriobo]

Expected Behavior

Allow using resourceSpec within pipeline definitions. The use case is related to runtime params, it is expected to use as a task input resource (git) with a parameter resulting from a previous task within the pipeline.

Example:

---
apiVersion: tekton.dev/v1alpha1
kind: Pipeline
metadata:
  name: pipeline-dev
spec:
  ...
  tasks:
    - name: get-servingrepository
      taskRef:
        name: get-servingrepository
      resources:
        inputs:
          - name: repository
            resource: source-repository
    - name: deploy-to-develop
      taskRef:
        name: kubectl-exec
      runAfter: ["get-servingrepository" , "build-and-push-image"]
      params:
        - name: kubectl-args
          value: ["apply", "-f", ".", "-n", "dev"]
      resources:
        inputs:
          - name: repository
            resourceSpec:
               type: git
               params:
                 - name: revision
                   value: develop
                 - name: url
                   value: $(tasks.get-servingrepository.results.serving-repository)

Actual Behavior

Get an error when creating the pipeline:

Error from server (InternalError): error when creating "pipeline/pipeline-dev_no_func.yaml": Internal error occurred: admission webhook "webhook.tekton.dev" denied the request: mutation failed: cannot decode incoming new object: json: unknown field "resourceSpec"

Additional Info

• Kubernetes version:

Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0", GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean", BuildDate:"2019-03-25T15:53:57Z", GoVersion:"go1.12.1", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"14+", GitVersion:"v1.14.9-eks-502bfb", GitCommit:"502bfb383169b124d87848f89e17a04b9fc1f6f0", GitTreeState:"clean", BuildDate:"2020-02-07T01:31:02Z", GoVersion:"go1.12.12", Compiler:"gc", Platform:"linux/amd64"}

• Tekton Pipeline version:
  0.10.1

[ghost]

Just wanted to clarify :- you are able to use a resourceSpec directly in your PipelineRuns, and I believe you should be able to refer to task results in the param values that you feed to a Pipeline Task from the PipelineRun.

I'm not 100% clear on the use case for putting a resourceSpec directly into a Pipeline. Could you describe a bit more the problem you're trying to solve?

[adrianriobo]

Hi @sbwsg sorry for the late reply... just let me try to explain my use case;

First, just clarify I am using tekton triggers to integrate github + tekton, so pipelineruns are managed by triggers and I just can play with paremeters in the request. to template the pipeline...

Got 1 project with my source code for my app: https://github.com/org/app/source-code.git
Got 1 project with serving file for my app: https://github.com/org/app/serving.git

I configured the webhook at source code project, so it will be executed on every push there...

My pipeline just: build code, build the image, push the image and finally deploy... to deploy it is required to clone the serving project (which contains the manifests)....

Binding parameters with triggers does not support any kind of string manipulation...so I can not get the url of the serving project.

With my previous example I can use the source code project url ... do some manipulation (one task) and then use it as input in other task, specially convenient as git resource. But to do this approach I require this resourceSpec at Pipeline definition.

Hope this helps to understand, please let me know if you have any other suggestions.

[adrianriobo]

Just found this and this issue regarding not promoting pipeline resources to beta so a task equivalence is released...

This will fit totally in my use case, so maybe there is no point to evolve pipeline resources

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

/close

Send feedback to tektoncd/plumbing.

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.