Add configuration types for built-in resolvers in ResolverRef

[abayer]

I keep thinking that it may make sense to eventually add real fields (with relevant structs) to ResolverRef for the built-in resolvers, so that you can just do

pipelineRef:
  git:
    org: foo
    repo: bar
    revision: main
    pathInRepo: a/b/c.yaml

Rather than the more elaborate generic params approach of

pipelineRef:
  resolver: git
  params:
  - name: org
    value: foo
  - name: repo
     value: bar
  - name: revision
     value: main
  - name: pathInRepo
    value: a/b/c.yaml

We could only support the git: ... syntax for built-in resolvers, but for those, we'd be able to do admission control-time validation, a simpler syntax, PipelineRun-wide defaults, etc.

So ResolverRef would change from:

type ResolverRef struct {
	Resolver ResolverName `json:"resolver,omitempty"`
	Params []Param `json:"params,omitempty"`
}

to:

type ResolverRef struct {
	Resolver ResolverName `json:"resolver,omitempty"`
	Params []Param `json:"params,omitempty"`

	Git     *GitResolverConfig     `json:"git,omitempty"`
	Bundle  *BundlesResolverConfig `json:"bundle,omitempty"`
	Cluster *ClusterResolverConfig `json:"cluster,omitempty"`
	Hub     *HubResolverConfig     `json:"hub,omitempty"`
}        

With these new structs:

type GitResolverConfig struct {
	Org        string `json:"org,omitempty"`
	Repo       string `json:"repo,omitempty"`
	URL        string `json:"url,omitempty"`
	PathInRepo string `json:"pathInRepo,omitempty"`
	Revision   string `json:"revision,omitempty"`
}

type BundlesResolverConfig struct {
	ServiceAccount string `json:"serviceAccount,omitempty"`
	Bundle         string `json:"bundle,omitempty"`
	Name           string `json:"name,omitempty"`
	Kind           string `json:"kind,omitempty"`
}

type ClusterResolverConfig struct {
	Name      string `json:"name,omitempty"`
	Kind      string `json:"kind,omitempty"`
	Namespace string `json:"namespace,omitempty"`
}

type HubResolverConfig struct {
	Name    string `json:"name,omitempty"`
	Kind    string `json:"kind,omitempty"`
	Version string `json:"version,omitempty"`
	Catalog string `json:"catalog,omitempty"`
}

The current resolver: git + params: ... would still work for the built-in resolvers, and would be how third-party resolvers need to be used. At runtime, GetPipelineFunc and GetTaskFunc would know about these new config types, and would be able to produce a ResolutionRequest for a ref using one of them that would be identical to a ResolutionRequest created for a ref using the full params syntax.

(oh, and we get the pipelineRef.git in this scenario because PipelineRef and TaskRef both inline ResolverRef)

/kind feature

[abayer]

cc @tektoncd/core-maintainers @chuangw6 - thoughts?

[abayer]

/assign

[vdemeester]

I am not sure I am too found of this approach, as I don't want for us to treat built-in resolvers any different from non built-in ones.
I think we should rather spend more time trying to find a way so that we could have "structured" syntax (aka no name+value param) for any type.

[abayer]

Also, since this idea came out of discussion prompted by #4710 (comment), we could have a new field on PipelineRun.Spec called resolverDefaults or somesuch, with this struct:

type PipelineRunResolverDefaults struct {
	Git     *GitResolverConfig     `json:"git,omitempty"`
	Bundle  *BundlesResolverConfig `json:"bundle,omitempty"`
	Cluster *ClusterResolverConfig `json:"cluster,omitempty"`
	Hub     *HubResolverConfig     `json:"hub,omitempty"`
}

[tekton-robot]

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.

[tekton-robot]

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.

[pritidesai]

@abayer any updated on this issue? Its been rotten, do you want to bring it back out of rotten? Thanks!

[dibyom]

I think we should rather spend more time trying to find a way so that we could have "structured" syntax (aka no name+value param) for any type.

Trigger interceptors allow the param value to be structured objects .

Though I now wish instead of param name/values, we just supported a single config field whose type could be structured JSON i.e. similar to this example but instead of a single param called config, we'd have have a field called config which takes a JSON that is customizable for each resolver.
Pipeline would just pass that on to each resolver which could then unmarshal it to its own config struct.

(This would address the syntax complexity issue, but not admission time validation)

[tekton-robot]

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.

[tekton-robot]

@tekton-robot: Closing this issue.

In response to this:

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.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.