Design: sources

[bobcatfish]

The work for this task is to design this feature and present one or more proposals (before implementing).

Expected Behavior

It should be possible for Pipelines to execute against multiple kinds of "sources".

The exact definition of what a "source" is a bit murky but generally we want this to be the same as a knative build CRD source, since ultimately that is how the Source will be used (once it is passed down to a Task as an input).

As far as the knative build CRD is concerned, a source could be:

• git
• gcs
• a custom image

And we would want to support other sources in the future as well, which should be arbitrarily extensible.

Also in #2 @pivotal-nader-ziada pointed out that we might want to be able to use outputs of Tasks as inputs to subsequent Tasks (e.g. mount a built image directly into a subsequent Task as a source).

Requirements

1. It should be possible to use git, gcs or a custom image as a source
2. It should be possible to add other kinds of sources (in a first iteration, this could require changing the pipline crd controller but in the long run it should be possible to do without forking the implementation)
3. For Tasks and Pipelines that need it, it should be possible to access additional information about sources, e.g. for a git source you might want to use the commit ID, the branch name, the committer, the author, etc.

Actual Behavior

In our examples we show what a possible github source could look like:

Additional Info

Though event triggering is outside the scope of the Pipeline CRD, we need to make sure that when an event DOES trigger a pipeline to run (by creating a PipelineRun and probably also a PipelineParams), that it is possible to provide all relevent info, so it might be worth exploring what info is contained in event such as github Pull Request events

See #11 re. ensuring the same sources/inputs are used throughout a Pipeline.

[bobcatfish]

This design work has been covered in #39! Thanks @shashwathi and @pivotal-nader-ziada !! 🍾