Figure out a way for git branch/tag to resolve to the same commit across multiple references in a Pipeline about resolution HOT 5 CLOSED

Couple of ideas:

1. When the git resolver returns a successfully fetched file it also sends back the resolved commit from the branch. Alongside this it could also return an alias hint that tells Pipelines "other refs with same branch should be updated to use commit instead".
2. Similar to above ^ except resolvers could publish this information once somewhere and pipelines could pick it up before any files are requested. This config could be another "ResourceRequest" type e.g.

kind: ResourceRequest
apiVersion: resolution.tekton.dev/v1alpha1
metadata:
  name: resolver-config-2938df38j92a8d9
  labels:
    resolution.tekton.dev/type: resolver-config
spec:
  params:
    resolver-type: foobar

Pipelines could submit this ResourceRequest the first time it sees a git type pipelineRef or taskRef. The git resolver would respond by writing a bit of json config into the status.data field. This config would include the information required for Pipelines to know that params branch and tag should be converted to commit:

// This json blob will be written by the foobar resolver and
// end up encoded as base64 in the status.data field of the
// ResourceRequest above so Pipelines can read it back:
{
  "address-narrowing": [
    { "from": "branch", "to": "commit" },
    { "from": "tag", "to": "commit" }
  ]
}

Pipelines could read this information and use it to inform decisions it makes about requesting pipelineRefs and taskRefs. For example, if it sees multiple taskRefs in a Pipeline that all share a branch param, it would know from this configuration that it should request the first taskRef and then re-use whatever commit is returned in place of each matching branch for all the other taskRefs. In this way every task from the same branch ends up pinned to the same commit. The libraries that tektoncd/resolution provides should be able to offer this functionality generically in some way so that the logic for it doesn't need to live in each client.

3. Resolvers could share a ConfigMap with this kind of configuration data that pipelines/other clients could then read it from.

from resolution.

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

from resolution.

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

/lifecycle rotten

Send feedback to tektoncd/plumbing.

from resolution.

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen with a justification.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/close

Send feedback to tektoncd/plumbing.

from resolution.

@tekton-robot: Closing this issue.

from resolution.