Users who specify a commitish of "master" may get unexpected behavior

[bobcatfish]

Expected Behavior

If a user provides a PipelineResource of type git to a PipelineRun and specifies master as the commitish, they probably meant that they want the entire Pipeline to run against the lastest commit at the time the PipelineRun starts.

Actual Behavior

What will actually happen is that every Task will re-fetch master when it executes, meaning that every Task in the Pipeline could end up using a different commit.

Additional Info

A couple ideas:

• Initialize PipelineResources in some way a the beginning of a PipelineRun
• Do not allow the git PipelineResource to specify master (probably a bad idea)
• Just let it be but make it very clear in our docs and intros what will happen
• ?

In #1392 we add the ability for the PipelineResource to at least record what commit it was used with.

[afrittoli]

Expected Behavior

If a user provides a PipelineResource of type git to a PipelineRun and specifies master as the commitish, they probably meant that they want the entire Pipeline to run against the lastest commit at the time the PipelineRun starts.

Actual Behavior

What will actually happen is that every Task will re-fetch master when it executes, meaning that every Task in the Pipeline could end up using a different commit.

Good point!

Additional Info

A couple ideas:

* Initialize PipelineResources in some way a the beginning of a PipelineRun

We could have a resource controller that prepares a specific version of the git repo on a PVC and serves it to the various Tasks - not an easy problem to solve though.

* Do not allow the git PipelineResource to specify master (probably a bad idea)

Well, the same problem exists with other branches as well...

* Just let it be but make it very clear in our docs and intros what will happen

+1
I think in use cases like CI/CD master will typically not be used, as the pipeline will be triggered with a very specific commit sha. However in other cases this might be an issue.

* ?

In #1392 we add the ability for the PipelineResource to at least record what commit it was used with.

Nice, this might allow tasks to clone the repo from the correct sha, but they somehow need to lookup into their parent pipeline to find the correct sha.

Alternatively could avoid re-cloning a git input resource and use the same input to all tasks, however this poses several issues:

• some kind of shared storage is required, unless we run all Tasks on the same node using affinity
• one Task may render the git clone "dirty"

[vdemeester]

This needs to get fixed before beta, and should be resolve, by not using PipelineResource as of today or with #1438, or with a re-design of PipelineResource, or a combinaison of those 😛

[bobcatfish]

TODO before beta release:

1. Document this clearly
2. Make sure our examples do not use master (since it would be a bad practice)

[bobcatfish]

With #1673 this has completely changed, going forward folks will likely be using Tasks to checkout from git so:

1. it will be explicit when the pull is happening
2. the results will show the actual commit that was pulled