Add git-clone-ssh

[jlpettersson]

Changes

This is a git-clone Task using SSH authentication that is easy to configure. With this Task Tekton only orchestrate tasks, but does not handle Secrets. The user declare the Secrets he has configured and Tekton does not manage them. This is similar to immutable infrastructure practices and serves as an alternative.

Here, runtime considerations, e.g. volumes and secret names is handled in a way as described in tektoncd/pipeline#2680
This depends on the bugfix in tektoncd/pipeline#2683

Closes #309

/kind feature

Submitter Checklist

These are the criteria that every PR should meet, please check them off as you
review them:

• Includes docs (if user facing)
• Commit messages follow commit message best practices
• [?] Yaml file complies with yamllint rules.

See the contribution guide
for more details.

[tekton-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
To complete the pull request process, please assign imjasonh
You can assign the PR to them by writing /assign @imjasonh in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[tekton-robot]

@jlpettersson: The following test failed, say /retest to rerun them all:

Test name	Commit	Details	Rerun command
pull-tekton-catalog-integration-tests	92fb4a0	link	/test pull-tekton-catalog-integration-tests

Full PR test history. Your PR dashboard.

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. I understand the commands that are listed here.

[chmouel]

Hi Jonas, thanks for submitting this,

Maybe I am misunderstanding how immutable infrastructure should look like but I am not sure what does it bring more from how we do natively with pipeline, i.e: https://github.com/tektoncd/pipeline/blob/master/docs/auth.md#using-ssh-authentication-in-your-own-git-tasks

If it's still something we want, maybe we can expand the git-clone task instead of having a new task ?

(and side note, I think we want to be OS agnostic and not target OSX pbcopy/pbpaste in the documentation)

[jlpettersson]

Maybe I am misunderstanding how immutable infrastructure should look like but I am not sure what does it bring more from how we do natively with pipeline, i.e: https://github.com/tektoncd/pipeline/blob/master/docs/auth.md#using-ssh-authentication-in-your-own-git-tasks

This is a setup where Tekton does not touch or move the Secrets. The user declare them, and Kubernetes mount them - Tekton is only involved in Task orchestration.

If it's still something we want, maybe we can expand the git-clone task instead of having a new task ?

It serves as an alternative. It is easier to handle secrets this way, in my opinion. But I am also fine with not letting it in to the Catalog. Since the authentication works in a different way, it is harder to converge with the existing git-clone since that is it's own Go and custom image. This is an alternative solution for the same job.

(and side note, I think we want to be OS agnostic and not target OSX pbcopy/pbpaste in the documentation)

That is a good point. I should update that section, if we want this in the Catalog.