git-clone unintended interaction with basic-auth workspace when using ssh directory workspace

[SjoerdvE]

Expected Behavior

When only binding to the ssh-directory (and output) workspaces the git-clone task should not fail because the basic-auth workspace is bound to the PipelineRun (but not to the git-clone Task).

Actual Behavior

We get an error:

STEP-CLONE

+ '[' true '=' true ]
+ cp /.git-credentials /home/git/.git-credentials
cp: can't stat '/.git-credentials': No such file or directory

Somehow the following line in the git-clone evaluates to true even though we didn't bind the basic-auth workspace to the task:

if [ "${WORKSPACE_BASIC_AUTH_DIRECTORY_BOUND}" = "true" ] ; then
  cp "${WORKSPACE_BASIC_AUTH_DIRECTORY_PATH}/.git-credentials" "${PARAM_USER_HOME}/.git-credentials"

In the error you can also so that even though WORKSPACE_BASIC_AUTH_DIRECTORY_BOUND evaluates to true that WORKSPACE_BASIC_AUTH_DIRECTORY_PATH is empty.

Steps to Reproduce the Problem

I'll omit company and unrelated stuff, and try to just show the setup that leads to this error.
We're running from GitHub with pipelinesascode, but I think it is a generic issue.

1. PipelineRun:

...
spec:
  pipelineRef:
    name: my-pipeline-v1-0
...
  workspaces:
    # Because the pipelinerun is started from the application repository, we need to
    # use the github-ssh secret to access the gitops repository.
    - name: basic-auth
      secret:
        secretName: "{{ git_auth_secret }}"
    - name: ssh-creds
      secret:
        secretName: github-ssh
...

2. Pipeline [my-pipeline-v1-0]

...
  workspaces:
    - name: basic-auth
    - name: ssh-creds
...
tasks:
...
    - name: gitops-git-clone
      taskRef:
        name: git-clone
      params:
        - name: url
          value: $(params.GITOPS_REPO_URL)
        - name: revision
          value: $(params.GITOPS_BRANCH)
        - name: subdirectory
          value: $(params.GITOPS_GIT_SUBDIRECTORY)
      workspaces:
        - name: ssh-directory
          workspace: ssh-creds
        - name: output
          workspace: output-pvc
          
    - name: app-git-clone
      taskRef:
        name: git-clone
      params:
        - name: url
          value: $(params.APP_REPO_URL)
        - name: revision
          value: $(params.APP_BRANCH)
        - name: subdirectory
          value: $(params.APP_GIT_SUBDIRECTORY)
      workspaces:
        - name: basic-auth
          workspace: basic-auth
        - name: output
          workspace: output-pvc
...

As you can see we have one git-clone task bound to ssh-directory and another git-clone task bound to basic-auth.

Additional Info

• For now we have a workaround by only using the ssh-directory workspace and completely removing the basic-auth workspace from our Pipeline.
• The reverse situation also leads to an error. app-git-clone bound only to basic-auth uses something from ssh-directory. This gives us the following error:

  {"level":"error","ts":1690968001.3274167,"caller":"git/git.go:53","msg":"Error running git [fetch --recurse-submodules=yes --depth=1 origin --update-head-ok --force myBranch]: exit status 128\nWarning: Permanently added 'github.com' (ED25519) to the list of known hosts.\r\[email protected]: Permission denied (publickey).\r\nfatal: Could not read from remote repository.\n\nPlease make sure you have the correct access rights\nand the repository exists.\n","stacktrace":"github.com/tektoncd/pipeline/pkg/git.run\n\tgithub.com/tektoncd/pipeline/pkg/git/git.go:53\ngithub.com/tektoncd/pipeline/pkg/git.Fetch\n\tgithub.com/tektoncd/pipeline/pkg/git/git.go:156\nmain.main\n\tgithub.com/tektoncd/pipeline/cmd/git-init/main.go:53\nruntime.main\n\truntime/proc.go:250"}
  

Thank you for looking into this.

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

[SjoerdvE]

We now use a work-around where we don't use the ssh-directory type of secrets when we need to have a basic-auth. So I regretfully don't have the reproduction configured to just run it and see if it still fails, but since the file (Task git-clone.yaml) has not been updated since I'm assuming it still fails.
/remove-lifecycle stale