feature request: snapshot pipeline data in pipelineRun for historical and repeatability purposes

[nader-ziada]

Expected Behavior

When a PipelineRun is created and it expands the pipeline reference, it should include the complete copy of the pipeline yaml so that if the pipeline changes, a user can tell which actual pipeline the results came from.

Actual Behavior

No information is about the Pipeline is added in the PipelineRun

Steps to Reproduce the Problem

1. kubectl get "your-pipeline-run" -o yaml
   will show the pipelineRun yaml with no information about the contents of the pipeline itself

Additional Info

• same applied to task and taskRun

[bobcatfish]

When a PipelineRun is created and it expands the pipeline reference, it should include the complete copy of the pipeline yaml so that if the pipeline changes, a user can tell which actual pipeline the results came from.

@pivotal-nader-ziada would this include also caching this Pipeline and using it in future reconcile loops? @tanner-bruce @mattmoor and @dwnusbaum were discussing this a bit in the slack chat, about wanting to make sure that changing a Pipeline midway through a run shouldn't affect runs in progress

(no worries if it makes more sense to tackle that separately)

Also @mattmoor 's suggestion about having a similar Revision model here (similar to knative/serving) could be relevant here.

Any other ideas?

[nader-ziada]

you mean creating a new version of the pipeline every time its changed? might be too much versions and we then the pipelineRun needs to have the ability to select which version to use if not latest.

To clarify, yes, I would expect the PipelineRun to make a copy of the Pipeline and use that in any reconcile until this run is finished.

[dwnusbaum]

I think that having the ability to select the version of a Pipeline/Task to run could be useful in some cases. For example, if you have a Task that is used in a few Pipelines, and you want to update it, you will probably want to test your updates on a single Pipeline to make sure it works before you force all Pipelines to use the new version of the Task for new builds. You can always do this with a kind of poor man's versioning in the Pipeline/Task name manually (i.e. PipelineNameV2, TaskName@scm-revision), but if this is a common use case then supporting it directly could be helpful.

Even if we did have Pipeline/Task versioning, and PipelineRun held references to immutable versions of Pipelines/Tasks, I think you'd still need to copy them into the PipelineRun in some way if we expect users to be getting build info by looking at the PipelineRun directly, so the issue as-described seems like something we definitely want.

[mattmoor]

Note that corev1.ObjectReference can support ResourceVersion: https://godoc.org/k8s.io/api/core/v1#ObjectReference

[bobcatfish]

you mean creating a new version of the pipeline every time its changed?

I think what we'd do is create a new version of the Pipeline when a PipelineRun is triggered, so something like:

1. User creates PipelineRun which uses Pipeline xyz
2. We create a 'Revision'/snapshot of Pipeline xyz, which the PipelineRun references
3. As the PipelineRun executes, it references the revision/snapshot of Pipeline xyz, meaning that if Pipeline xyz changes, those changes won't be picked up by the executing Run

if you have a Task that is used in a few Pipelines, and you want to update it, you will probably want to test your updates on a single Pipeline to make sure it works before you force all Pipelines to use the new version of the Task for new builds.

That's an interesting use case @dwnusbaum - thanks for the tip @mattmoor ! - sounds to me like we need to get an issue going to talk about the story around how a person would try out changes to their Pipeline (ideally we can get to a point where you can make changes to your Pipeline yamls and try them out in a PR or similar without effecting your actual Pipeline)

[abayer]

Playing into this, I just asked a question in slack:

Also, how, if at all, do we stop reconciling a PipelineRun upon completion? I may very well just be misunderstanding the general architecture, but it looks to me like the reconciler will just keep going forever - so that if you did something batty like somehow added a new Task to the Pipeline after the PipelineRun had completed, it’d end up picking up and running that new Task too. Am I missing something?

As I said, I could be misreading how this actually works at the moment, but it sure feels like adding a Task to a Pipeline after an associated PipelineRun (ok, and maybe some other actions to create/associate a TaskRun etc too, not sure) thinks it has completed could lead to it picking back up again.

[bobcatfish]

but it sure feels like adding a Task to a Pipeline after an associated PipelineRun (ok, and maybe some other actions to create/associate a TaskRun etc too, not sure) thinks it has completed could lead to it picking back up again.

In the current behaviour this wouldn't happen (i dont think) b/c what triggers the reconcile to occur is:

• If the PipelineRun itself changes
• If any resources created by the PipelineRun change (e.g. TaskRuns)

(Created #299 to look into this further)

[bobcatfish]

@imjasonh relevant to your current investigations!

[tekton-robot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.

/lifecycle rotten

Send feedback to tektoncd/plumbing.