Pipeline: Question: A way to pass variables between task steps.

[adjavaherian]

Is there a way set an env variable in one task step and then have the subsequent task step be able to read that in or interpolate it in an arg? Admittedly, I don't fully understand if env variables are shared between multiple images / steps in the same task.

What I want to do is have a little script in one task step read a file and set env variables, so that the subsequent task step (kaniko) can get things dynamically from env variables set in the container, rather than passed in as params to the task run eg. I won't know the name of Dockerfile or path to context until I read the file from git source.

Here's my question on SO, which also appears to be the first Tekton tag 🎉 .

Very cool stuff, thanks!

https://stackoverflow.com/questions/58561514/pass-env-vars-from-one-tekton-task-step-to-the-next

rough example of what I want to do.

apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: example-task-name
spec:
  inputs:
    resources:
      - name: workspace
        type: git
    params:
      - name: pathToDockerFile
        type: string
        description: The path to the dockerfile to build
        default: /workspace/workspace/Dockerfile
  outputs:
    resources:
      - name: builtImage
        type: image
  steps:
    - name: ubuntu-example
      image: ubuntu
      args: "export FOO=bar"
    - image: gcr.io/example-builders/build-example
      command: ["echo $FOO"]

[sbwsg]

Is there a way set an env variable in one task step and then have the subsequent task step be able to read that in or interpolate it in an arg?

There isn't a way to export environment variables from one step into another.

A different possible approach would be to use files on disk for a similar purpose. All steps in a Task share a workspace volume. This allows the following:

apiVersion: tekton.dev/v1alpha1
kind: Task
metadata:
  name: example-task-name
spec:
  inputs:
    resources:
      - name: workspace
        type: git
    params:
      - name: pathToDockerFile
        type: string
        description: The path to the dockerfile to build
        default: /workspace/workspace/Dockerfile
  outputs:
    resources:
      - name: builtImage
        type: image
  steps:
    - name: write-to-workspace
      image: ubuntu
      script: |
        #!/usr/bin/env bash
        echo "bar" > /workspace/FOO
    - name: read-from-workspace
      image: ubuntu
      script: |
        #!/usr/bin/env bash
        export FOO=$(cat /workspace/FOO)
        echo $FOO

(I'm using the script field here which won't be released until 0.9 but makes writing shell scripts in steps much clearer).

[vtereso]

This is similar to https://github.com/tektoncd/pipeline/issues/1273. However, inter-Task communication can be achieved by saving to the mounted volume that is shared between steps or creating your own. I think you should be able to create a directory within /workspace to save such state. Someone correct me on the pathing if I am wrong 👀 Seems like @sbwsg beat me to the comment haha

[bobcatfish]

Not a solution but an interesting approach to a similar problem: @afrittoli added an init container for our dogfood cron pods that writes a script to a known location that initializes environment variables:

https://github.com/tektoncd/plumbing/blob/1062bd15a7354972b5a0dcd3db5912bc9b5f64ab/tekton/config/nightly-release-cron-base/trigger-with-uuid.yaml#L27-L42

[adjavaherian]

Cool, thanks. Yeah I didn't want to have to do the shared volume mount + cat thing, but I guess if need be, I'll use that technique. The example above is great. Maybe this shared volume with the exports can be built into to the underlaying task CRDs? Sounds like a useful feature.

[sbwsg]

We're working on a feature called workspaces that will eventually expose / override the shared volume stuff as part of the tekton CRDs. The WIP PR is up at https://github.com/tektoncd/pipeline/pull/1639

We're also designing / working on the output params feature described in #1273 as @vtereso mentioned. I haven't heard any strong dissents against that feature and it sounds to me at the moment like there is some support in the community for it. Hopefully only a matter of time until it's implemented :crossed_fingers:.

Given that the original question has been answered I'm going to close out this thread in favor of ongoing discussion on the above issues.