If I pass something that can be interpreted as a variable on a task input it will break the task with a non-existent variable error

[viniagostini]

Expected Behavior

print the literal {"key": "$(params.a)"}

Actual Behavior

CouldntGetTask error
failed to create task run pod "some-task-run-2": non-existent variable in "echo {\"key\": \"$(params.a)\"}\n": steps[0].script. Maybe missing or invalid Task my-ns/some-task

Steps to Reproduce the Problem

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: some-task
  namespace: my-ns
spec:
  params:
    - name: input
  steps:
    - name: print
      image: alpine
      script: |
        echo $(params.input)

---

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: some-task-run-2
  namespace: my-ns
spec:
  taskRef:
    name: some-task
  serviceAccountName: tekton-triggers-admin
  params:
    - name: input
      value: '{"key": "$(params.a)"}'

I ran into this problem trying to pass a TaskRun cloud event payload as a param to another Task. For now, I have a workaround using CEL on the EventListener to replace every $(params. for an empty string like so

- name: "overlays"
   value:
     - key: cePayload
        expression: body.marshalJSON().replace('$(params.','')

This works fine for me now but I see some unexpected behaviors happening in the future, so it would be nice if the task could escape or not try to interpret the values on the params.

Additional Info

• Kubernetes version:

  Output of kubectl version:

Client Version: version.Info{Major:"1", Minor:"23", GitVersion:"v1.23.3", GitCommit:"816c97ab8cff8a1c72eccca1026f7820e93e0d25", GitTreeState:"clean", BuildDate:"2022-01-25T21:17:57Z", GoVersion:"go1.17.6", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"21+", GitVersion:"v1.21.5-eks-bc4871b", GitCommit:"5236faf39f1b7a7dabea8df12726f25608131aa9", GitTreeState:"clean", BuildDate:"2021-10-29T23:32:16Z", GoVersion:"go1.16.8", Compiler:"gc", Platform:"linux/amd64"}

• Tekton Pipeline version:

Client version: 0.23.0
Pipeline version: v0.28.2
Triggers version: v0.18.0
Dashboard version: v0.24.1

[Aleromerog]

/assign @Aleromerog

[Aleromerog]

After some attempts of not evaluating strings inside quotes, we realized there may be cases when a user would want variables inside quotes to be treated as variables. So there are a couple of options for this:

1. We use something besides " or ' to indicate we should not escape e.g. $(params.&lt;&gt;) or $$(params.<>)
2. We use "", or ' but use a feature flag at the controller level to decided which behaviour to use
3. We use an annotation on the task/taskrun to decide which behaviour to use
4. Evaluate the string at a task scope level with only the variables on that scope

Maybe option 1 is a quick and easy fix, but I'd like to have some feedback on this.
@vdemeester wdyt?

[vdemeester]

For me, the easiest fix would be to not validate (nor interpolate) things in Params of a Task. But with embedded Task, it seems it could be a problem. I think the approach in #4835 (comment) would work fine as well.

[Aleromerog]

I've addressed this bug for TaskRuns, but it still needs to be addressed for PipelineRuns. Here's an example PipelineRun where this error appears:

apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
  name: some-pipeline
  namespace: my-ns
spec:
  params:
  - name: input
  tasks:
  - name: foo
    taskSpec:
    params:
    - name: input
      value: $(params.input)
    steps:
    - name: print
      image: alpine
      script: |
        echo $(params.input)
---
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
  name: some-pipeline-run-2
  namespace: my-ns
spec:
  pipelineRef:
    name: some-pipeline
  serviceAccountName: tekton-triggers-admin
  params:
    - name: input
      value: '{"key": "$(params.a)"}'

[Aleromerog]

Merged a PR for this.

[jerop]

Thanks @Aleromerog!

[lbernick]

I was able to reproduce this bug on main. It looks like it was reintroduced by #4891

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
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 with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/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 with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[tekton-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/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 with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

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