Creating a pipeline with task dependencies

[jromero]

I'm in the process of creating a pipeline that would go in the catalog. This new pipeline has the need to clone source from git. What is the best way to incorporate this functionality?

The way I see it, I have a few options:

1. Create my own task in the pipeline definition that provides the git clone functionality.
   • Pro: Ease of use. Users don't need to install anything else.
   • Con: Need to reimplement and maintain logic similar to existing git-clone task.
2. Declare the git-clone task dependency in the README.md
   AFAICT there is no way to define dependencies in the pipeline definition and the pipeline would install even if referenced tasks are not installed.
   • Pro: No need to reimplement logic / results of existing git-clone task.
   • Con: Subpar user experience by having to install depencies.
3. Use Tekton bundles
   • Pro: No need to reimplement logic / results of existing git-clone task
   • Pro: Ease of use (if already available and enabled).
   • Con: Needs to be enabled in the Tekton install.
   • Con: Are there pre-built bundles for things in the catalog?
4. Use git PipelineResource
   • Pro: No need to reimplement logic / results of existing git-clone task
   • Con: Deprecated (strayed away from using these)

At this point in time, I'm leaning towards Option 2.

[ghost]

I think Option 2 is the best short term solution. The git-clone task that one org uses might be different to the git-clone task another org uses - for example, one might use a private image that has been approved by their security team or may be holding back to an older version. For that reason I think it's best to declare the dependency in the README and let the user decide to use their own or install from the catalog.

We have a TEP (tekton enhancement proposal) open at the moment looking at pipelines in the catalog here: tektoncd/community#352

[jerop]

@afrittoli opened an issue a while back about supporting alternative implementations of a specific task which seems relevant to this discussion, this could be another option for the scenario above

[jerop]

and we may need to consider this option for catalog tasks generally i.e. can we support the multiple versions/alternatives of the same "core" task in the catalog? (cc @bobcatfish)