TaskRun fails with folder already exists error

[R2wenD2]

Scenario: A single task using a shared workspace to share data between steps in the task, clones a repo onto the workspace in the first step, and in a subsequent step uses a subdir of the repo as a workingdir. This causes the clone to fail since the dir already exists.

We do this in a single task because Tekton Chains doesn't support Pipeline level provenance so we need to keep steps in the same task in order to generate complete provenance.

Error Logs:

2022/09/14 08:07:24 Decoded script /tekton/scripts/script-4-h66wt
2022/09/14 08:07:24 Decoded script /tekton/scripts/script-5-9zvfz
fatal: destination path 'Pillow' already exists and is not an empty directory.

[chitrangpatel]

I think I was able to recreate this issue with the following yaml:

apiVersion: tekton.dev/v1beta1 
kind: TaskRun                  
metadata:
  generateName: steps-run-in-order-
spec:
  workspaces:                  
    - name: my-workspace
      emptyDir: {}
  taskSpec:
    workspaces:
      - name: my-workspace     
    steps:
    - image: ubuntu
      script: |
        mkdir $(workspaces.my-workspace.path)/subdir
        echo "hello" > $(workspaces.my-workspace.path)/subdir/hi.txt
    - image: ubuntu
      workingDir: /workspace/my-workspace/subdir
      script: |
       cat $(workspaces.my-workspace.path)/subdir/hi.txt 

In my case, I was getting the following error:

 mkdir: cannot create directory '/workspace/my-workspace/subdir': File exists  

My guess is that when using workingDir, that directory is created in advance and so anything that wants to create the same directory might be failing (in your case, git clone probably wants to create the directory first)

[chitrangpatel]

WorkingDir is initialized via the initContainers. It is executed before all other steps. So when we specify the workingDir, that directory will be created before the first step. And so when git clone wants to clone something, there is a non-empty directory since the workingDir was already set to a subdirectory.

[chitrangpatel]

Discussion point since I am probably missing a lot of context here:

If one of the steps (could be the last step) wants to use a workingDir, it is created before all the steps in an initContainer. Shouldn't the workingDir be created (if not already exists) when required? i.e. when the step is to be run?

[dibyom]

Tekton ensures any workingDir under /workspace are initialized before the step starts running

This is mentioned in a comment here but I don't see it mentioned in our docs: https://tekton.dev/vault/pipelines-v0.14.3/tasks/#defining-steps

We should at least update our docs so that this is less confusing

[atulag91]

Tried setting the workingDir to $(workspaces.<workspace-name>.path) but still getting the same error for the above issue. As mentioned above, it seems like if workingDir is set to a sub-directory for any tasks, then its initialized before any steps runs even if $(workspaces.<workspace-name>.path) is used.

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