pipeline: Arguments of type array cannot be access via index

Expected Behavior

When using a parameter of type Array and trying to access access a specific index, the variable substitution does not occur. Assuming the following pipeline spec, I would expect the tasks generated to have the value 'false' be substituted.

apiVersion: tekton.dev/v1beta1
kind: Pipeline
...
spec:
  params:
    - disabled:
        - 'false'
        - 'false'
        - 'false'
        - 'false'
...
  tasks:
    - name: ...
      params:
        - name: disabled
          value: '$(params.disabled[2])'

Actual Behavior

As can be seen here once the pipeline is run (seen through dashboard) , the variable is not substituted. Screen Shot 2020-09-18 at 12 58 46 PM

Steps to Reproduce the Problem

Outlined above

Additional Info

  • Kubernetes version:

    Output of kubectl version:

Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.8", GitCommit:"211047e9a1922595eaa3a1127ed365e9299a6c23", GitTreeState:"clean", BuildDate:"2019-10-15T12:11:03Z", GoVersion:"go1.12.10", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"15+", GitVersion:"v1.15.12-gke.2", GitCommit:"fb7add51f767aae42655d39972210dc1c5dbd4b3", GitTreeState:"clean", BuildDate:"2020-06-01T22:20:10Z", GoVersion:"go1.12.17b4", Compiler:"gc", Platform:"linux/amd64"}
  • Tekton Pipeline version:

    Output of tkn version or kubectl get pods -n tekton-pipelines -l app=tekton-pipelines-controller -o=jsonpath='{.items[0].metadata.labels.version}'

Client version: 0.11.0
Pipeline version: v0.14.3
Triggers version: v0.7.0

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 23 (4 by maintainers)

Commits related to this issue

Most upvoted comments

@sbwsg another alternative we could consider, if CEL custom tasks is promoted from experimental, is deprecating array params and supporting string params only for simplicity and flexibility (avoiding to implement our own expression syntax)

Very interesting! I agree this would solve a lot of different problems we have with the existing array syntax’s complexity and offer flexibility on syntax choice / behaviour. I wonder how we could handle situations where a user passes an array of varying length and this needs to be merged / appended to a Step’s command or args list.

Keeping this one alive because I think array params could still use some improvements like this to make them far more useful.

@sbwsg another alternative we could consider, if CEL custom tasks is promoted from experimental, is deprecating array params and supporting string params only for simplicity and flexibility (avoiding to implement our own expression syntax)