Optional Workspaces

[ghost]

Expected Behavior

A workspace can be declared by a Task but marked as optional.

This would be useful in the following scenario: A task wants to perform a git-clone. In order for the task to support both authenticated and unauthenticated clones the user should be able to choose whether an SSH credential is provided or not. The task declares a workspace "ssh-directory" which is marked as optional. Users who want to use the task to make credentialled git-clones are able to provide a Workspace backed by a Kubernetes Secret. Users who don't want to make credentialled clones are able to skip providing any workspace at all.

A slightly alternative design to simply declaring a workspace "optional" would be to allow the Task author to declare a "default" workspace kind (such as emptyDir) which is then overwritten by a TaskRun if it's provided there. See @bobcatfish's comment here: #2058 (comment)

Actual Behavior

At the moment workspaces in a task must be provided by TaskRuns using that task.

Related

Catalog git-clone Doesn't support authenticated requests to git repos out of the box

[dibyom]

/kind feature

[chanseokoh]

At the moment workspaces in a task must be provided by TaskRuns using that task.

Is this true? Isn't this already working? For example, I had in my Task sepc

  workspaces:
  - name: docker-secret

and I don't get any error when I don't specify anything in my TaskRun. Of course, if I do provide a secret like below, the workspace is accessible at /workspace/docker-secret.

 workspaces:
  - name: docker-secret
    secret:
      secretName: registry-credentials-docker

[ghost]

Is this true?

It's supposed to be true. If it isn't that would be some unexpected / buggy behaviour (at least as the implemented design stands right now).

[ghost]

Two more use-cases:

1. Allow a single catalog Task to support both Workspaces and PipelineResources in the same location. Example:

apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
  name: build-code-from-pipelineresource-or-workspace
spec:
  resources:
    inputs:
      - name: source
        type: git
        optional: true
  workspaces:
    - name: source
      optional: true
      description: This workspace can be provided, or you can give a `git` PipelineResource. Up to you!
    - name: output
      description: Built binary ends up here.
  steps:
    - name: test
      image: golang
      workingDir: /workspace/source
      script: |
        # This will run either in the pipeline resource git clone or in the provided source workspace
        go build -o /workspace/output/foo .

2. Allow a TaskRun to ignore test results written to a workspace by simply not providing one.

apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: test-code-but-discard-results-tr
spec:
  workspaces:
  - name: source
    description: source code to test.
  - name: out
    optional: true
    description: test results will be written here if a workspace is provided.
  steps:
    - name: test
      image: golang
      workingDir: /workspace/source
      script: |
        go test . > /workspace/out/test-results.xml
---
apiVersion: tekton.dev/v1beta1
kind: TaskRun
metadata:
  name: test-code-but-discard-results-tr
spec:
  workspaces:
  - name: source
    persistentVolumeClaim:
      claimName: pvc-where-my-code-is
    # Notice: no "out" workspace provided here. Results will be discarded at end of run.

[ghost]

Another potential use-case:

A task generates a manifest of files modified/uploaded/downloaded during its execution. That manifest could be 1 entry long or many, many, many entries. This rules out results since their length is quite restricted. So instead the task accepts an optional workspace on to which the manifest is copied. If the user wants that manifest they provide the workspace. If the task author decides to, they could also only generate that manifest if the workspace is provided.

[bioball]

Another use-case: a Task can accept an optional cache to speed up builds.

[ghost]

Another use-case: a Task can accept an optional cache to speed up builds.

Awesome, thanks, I've added this as another user story in the TEP.

[coryrc]

So what's the next step? Is there a milestone or anything I can follow along with and/or participate in the implementation?

[ghost]

TEP was approved in tektoncd/community#169 and is moving to implementable status. I'm working on implementation this week and next.

[ghost]

Fixed in #3274

[ghost]

Released in 0.17