[TEP-0133] Configure Default Resolver

This commit adds a new TEP: Configure Default Resolver.

This commit adds proposal and implementation details to introduce a new field `default-resolver-type` in the ConfigMap to configure the default resolver type in Tekton. The design fulfills the requirement of [feature request #5907][#5907]

/kind tep

[#5907]: tektoncd/pipeline#5907

teps/0133-configure-default-resolver.md

@@ -0,0 +1,163 @@
+---
+status: implementable
+title: Configure Default Resolver
+creation-date: '2023-03-03'
+last-updated: '2023-03-03'
+authors:
+- '@QuanZhang-William'
+- '@vdemeester'
+collaborators: []
+---
+
+# TEP-0133: Configure Default Resolver
+<!-- toc -->
+- [Summary](#summary)
+- [Motivation](#motivation)
+  - [Goals](#goals)
+  - [Use Cases](#use-cases)
+      - [Custome Resolver](#custom-resolver)
+      - [Common Remote Resource Storage](#common-remote-resource-storage)
+- [Proposal](#proposal)
+- [Design Details](#design-details)
+    - [Populate Default Resolver](#populate-default-resolver)
+    - [Validation Webhook](#validation-webhook)
+- [Design Evaluation](#design-evaluation)
+  - [Simplicity](#simplicity)
+  - [Flexibility](#flexibility)
+  - [Reusability](#reusability)
+- [Alternatives](#alternatives)
+- [References](#references)
+<!-- /toc -->
+
+## Summary
+This TEP proposes to support configurable default `Resolver` type to improve the simplicity of *Remote Resolution*. This TEP builds on prior work [TEP-0060].
+
+## Motivation
+Today, Tekton users must explicitly specify the `Resolver` type to use Remote Resolution, which brings verbosity when authoring the input yaml file.
+
+### Goals
+- Allow cluster operators to configure a default `Resolver` type when using Tekton Pipelines .
+- The default `Resolver` can either be a built-in type (`hub`, `git`, `cluster`, and `bundle`) or a [Custom Resolver].
+
+### Use Cases
+#### Custom Resolver
+As a company cluster operator, I may have my own [Custom Resolver] which is used by most of the cluster users when resolving remote resources. I may want to simplify the user experience with such default values at the authoring time.
+
+#### Common Remote Resource Storage
+As a company cluster operator, all of the company's `Tasks` and `Pipelines` are stored in the same GitHub repo. I may not want to enforce the company users to specify the `Resolver` type for every `TaskRun` and `PipelineRun` (see the [issue #5907]).
+
+## Proposal
+To support the configurable default `Resolver` type, we propose to introduce a new field `default-resolver-type` in the [config-defaults.yaml][config-defaults]. 
+
+With the `default-resolver-type` field configured, authors can create `TaskRun` and `PipelineRun` without setting the `resolver` field in the yaml input. 
+
+For example:
+
+```yaml
+apiVersion: tekton.dev/v1beta1
+kind: TaskRun
+metadata:
+ name: demo-task-run
+spec:
+ taskRef:
+   #resolver: git
+   params:
+   - name: url
+     value: https://github.com/tektoncd/catalog.git
+   - name: revision
+     value: main
+   - name: pathInRepo
+     value: task/golang-build/0.1/golang-build.yaml
+```
+
+Here is another example where a `Pipeline` tries to resolve a remote `PipelineTask`:
+
+```yaml
+apiVersion: tekton.dev/v1beta1
+kind: Pipeline
+metadata:
+  name: demo-pipeline
+spec:
+  tasks:
+  - name: post-message
+    taskRef:
+      #resolver: hub
+      params:
+      - name: kind
+        value: task
+      - name: name
+        value: github-add-comment
+      - name: version
+        value: "0.7"
+    params:
+    ...
+```
+
+If the `default-resolver-type` field is **not** configured, the Tekton Pipeline project should behave the same way as before (i.e. the *validation webhook* should fail with a missing `resolver` field).
+
+To keep this new feature as "opt-in", we propose **not** to specify a default value to this field. 
+
+``` yaml
+  # Setting this flag to a resolver type as the default resolver
+  default-resolver-type: ""
+```
+
+The resource author can overwrite the default `Resolver` by explicitly setting it in the yaml input.
+
+## Design Details
+### Populate Default Resolver
+We propose to populate the default value in the current `SetDefault` function of `TaskRunSpec` and `PipelineSpec`.
+
+Taking `TaskRunSpec` as an example:
+
+```go
+// SetDefaults implements apis.Defaultable
+func (trs *TaskRunSpec) SetDefaults(ctx context.Context) {
+  cfg := config.FromContextOrDefaults(ctx)
+  if trs.TaskRef != nil {
+    if trs.TaskRef.Kind == "" {
+      trs.TaskRef.Kind = NamespacedTaskKind
+    }
+    if trs.TaskRef.Name == "" && trs.TaskRef.Resolver == "" {
+      trs.TaskRef.Resolver = ResolverName(cfg.Defaults.DefaultResolverType)
+    }
+  }
+```
+
+### Validation Webhook
+If the `resolver` is neither explicitly provided nor set by default, the *validation webhook* should fail the execution.
+
+The current validation webhook logic already covers such a scenario given the default value population happens beforehand in the *mutation webhook* phase.
+
+To support defaulting to `Custom Resolver` types, the validation webhook should not check the value specified in the `default-resolver-type` field.
+
+## Design Evaluation
+### Simplicity
+This design simplifies the user experience at resource authoring time where authors can skip specifying the `resolver` field when applicable.
+
+This design also provides a simple solution to cluster operators to configure the default `Resolver` type when necessary.
+
+### Flexibility
+This design exhibits flexibility by allowing to default to `Custom Resolver` based on each team/company's needs
+
+### Reusability
+This design inhibits the reusability at the authoring time since we cannot guarantee that a `TaskRun` that works in cluster A can necessarily work in cluster B when the default `Resolvers` are configured differently.
+
+However, authors can overwrite the default `resolver` by explicitly setting the field which mitigates this drawback. In addition, we should provide clear documentation highlighting this reusability risk when a resource needs to be applied across clusters.
+
+## Alternatives
+Instead of setting the default `Resolver` in the [config-defaults.yaml][config-defaults], we could put the configuration in the [resolver feature flag]. 
+
+However, the [resolver feature flag] resides in the `tekton-pipelines-resolver` namespace instead of the `tekton-pipelines` namespace. This alternative introduces an extra dependency to the `tekton-pipelines-resolver` namespace for *Tekton Webhooks and Controllers* while bringing no extra benefit.
+
+We can revisit this alternative if we decide to merge the `tekton-pipelines-resolver` back to the `tekton-pipelines` namespace in the future.
+
+## References
+- [TEP-0060: Remote Resolution][TEP-0060]
+
+[TEP-0060]: https://github.com/tektoncd/community/blob/main/teps/0060-remote-resource-resolution.md
+[custom Resolver]: https://github.com/tektoncd/pipeline/tree/main/docs/resolver-template
+[issue #5907]: https://github.com/tektoncd/pipeline/issues/5907
+[config-defaults]: https://github.com/tektoncd/pipeline/blob/main/config/config-defaults.yaml
+[resolver feature flag]: https://github.com/tektoncd/pipeline/blob/main/config/resolvers/config-feature-flags.yaml
+[git resolver ConfigMap]: https://github.com/tektoncd/pipeline/blob/main/config/resolvers/git-resolver-config.yaml

teps/README.md

@@ -119,3 +119,4 @@ This is the complete list of Tekton TEPs:
 |[TEP-0127](0127-larger-results-via-sidecar-logs.md) | Larger Results via Sidecar Logs | implemented | 2022-12-15 |
 |[TEP-0128](0128-scheduled-runs.md) | Scheduled Runs | implementable | 2022-12-20 |
 |[TEP-0129](0129-multiple-tekton-instances-per-cluster.md) | Multiple Tekton instances per cluster | proposed | 2023-01-11 |
+|[TEP-0133](0133-configure-default-resolver.md) | Configure Default Resolver | implementable | 2023-03-03 |