Update triggers reference from master to main 🧙

roadmap.md

@@ -9,7 +9,7 @@ for Tekton Pipelines but some sneak peeks at other projects as well.
 - [Results](#results)
 - Tekton Projects
   - [Pipeline](https://github.com/tektoncd/pipeline/blob/master/roadmap.md)
-  - [Triggers](https://github.com/tektoncd/triggers/blob/master/roadmap.md)
+  - [Triggers](https://github.com/tektoncd/triggers/blob/main/roadmap.md)
   - [Catalog](https://github.com/tektoncd/catalog/blob/master/roadmap.md)
   - [Dashboard](https://github.com/tektoncd/dashboard/blob/master/roadmap.md)
   - [CLI](https://github.com/tektoncd/cli/blob/master/ROADMAP.md)

teps/0002-custom-tasks.md

@@ -402,7 +402,7 @@ This requires integrators to write CRD types and controllers in order to impleme
 
 1.  As in previous iterations of this design (documented more fully in the Google Doc), require implementors to define and support two CRD types, instead of one. See the doc for full explanation of the trade-offs.
 
-1. Allow users to instantiate arbitrary kubernetes objects by providing their entire content inline. In this approach, users would be create instances of their own custom CRDs, e.g. `CELRun`, by providing the entire body inline, much like [triggertemplates](https://github.com/tektoncd/triggers/blob/master/docs/triggertemplates.md).
+1. Allow users to instantiate arbitrary kubernetes objects by providing their entire content inline. In this approach, users would be create instances of their own custom CRDs, e.g. `CELRun`, by providing the entire body inline, much like [triggertemplates](https://github.com/tektoncd/triggers/blob/main/docs/triggertemplates.md).
 
    * pros: ultimiate flexibility
 

teps/0008-support-knative-service-for-triggers-eventlistener-pod.md

@@ -146,7 +146,7 @@ spec:
 This is exactly the same whatever we have right now with default.
 The reason to move `serviceAccountName`, `podTemplate`, 
 to `kubernetesResource` field is because those are part of [WithPodSpec{}](https://github.com/knative/pkg/blob/master/apis/duck/v1/podspec_types.go#L49) duck type
-and which helps to support any of the pod and container field without hardcoding in [podTemplate](https://github.com/tektoncd/triggers/blob/master/pkg/apis/triggers/v1alpha1/event_listener_types.go#L62).
+and which helps to support any of the pod and container field without hardcoding in [podTemplate](https://github.com/tektoncd/triggers/blob/main/pkg/apis/triggers/v1alpha1/event_listener_types.go#L62).
 
 1.If user specify podSpec fields.  
 ```yaml
@@ -337,7 +337,7 @@ With all of the above implementation we should have `Knative` dependency as vend
 ## Open Points
 
 As per the proposal `kubernetesResource` will have `serviceType` and `spec` which is [WithPodSpec{}](https://github.com/knative/pkg/blob/master/apis/duck/v1/podspec_types.go#L49) duck type
-so the created Deployment/Service will get the information of annotation/labels if provided as part of [EventListener](https://github.com/tektoncd/triggers/blob/master/pkg/apis/triggers/v1alpha1/event_listener_types.go#L42-L44).
+so the created Deployment/Service will get the information of annotation/labels if provided as part of [EventListener](https://github.com/tektoncd/triggers/blob/main/pkg/apis/triggers/v1alpha1/event_listener_types.go#L42-L44).
 
 But there is discussion thread [here](https://github.com/tektoncd/community/pull/186#issuecomment-685250556) 
 where there is a point like user should get the way to specify annotation/labels to Deployment/Service.

teps/0022-trigger-immutable-input.md

@@ -100,15 +100,15 @@ Today with overlays, users have the ability to modify incoming event payloads
 either with CEL or Webhook interceptors.
 
 For example, the following
-[CEL Interceptor](https://github.com/tektoncd/triggers/blob/master/docs/eventlisteners.md#CEL-Interceptors)
+[CEL Interceptor](https://github.com/tektoncd/triggers/blob/main/docs/eventlisteners.md#CEL-Interceptors)
 can modify the incoming event payload to include a shortened SHA:
 
 ```yaml
 - key: body.pull_request.head.short_sha
   expression: "truncate(body.pull_request.head.sha, 7)"
 ```
 
-[Webhook Interceptors](https://github.com/tektoncd/triggers/blob/master/docs/eventlisteners.md#Webhook-Interceptors)
+[Webhook Interceptors](https://github.com/tektoncd/triggers/blob/main/docs/eventlisteners.md#Webhook-Interceptors)
 can provide similar functionality with their own custom code, but they are also
 required to pass back bodies in responses if they wish to preserve data.
 

teps/0026-interceptor-plugins.md

@@ -59,17 +59,17 @@ Interceptors have two API surfaces:
 1. Configuration: This is the part of the EventListener spec where users
 configure the interceptor to use (e.g. the CEL interceptor) along with
 addition configuration e.g. a CEL filter expression
-([example](https://github.com/tektoncd/triggers/blob/master/examples/github/github-eventlistener-interceptor.yaml#L10))
+([example](https://github.com/tektoncd/triggers/blob/main/examples/github/github-eventlistener-interceptor.yaml#L10))
 2. The [runtime
-interface](https://github.com/tektoncd/triggers/blob/master/pkg/interceptors/interceptors.go#L30)
+interface](https://github.com/tektoncd/triggers/blob/main/pkg/interceptors/interceptors.go#L30)
 that defines what information gets passed on to the interceptor code for
 processing and what information the interceptor has to return (e.g a modified
 event body, a yes/no on whether to continue processing etc.)
 
 Today, interceptors come in two flavors -
-[built-in](https://github.com/tektoncd/triggers/blob/master/docs/eventlisteners.md#interceptors)
+[built-in](https://github.com/tektoncd/triggers/blob/main/docs/eventlisteners.md#interceptors)
 and
-[webhook](https://github.com/tektoncd/triggers/blob/master/docs/eventlisteners.md#Webhook-Interceptors).
+[webhook](https://github.com/tektoncd/triggers/blob/main/docs/eventlisteners.md#Webhook-Interceptors).
 They differ both in the end user interface as well as the runtime interface.
 Built in interceptors are part of the Triggers source tree and are executed
 as in process function calls. Users can provide additional configuration
@@ -169,7 +169,7 @@ See the [Design Details](#design-details) section below for more.
 
 3. Backwards Compatibility
 
-    This model [diverges](#http-interface) from the existing WebHookInterceptor model. For backwards compatibility, we can keep supporting the existing [WebhookInterceptor interface](https://github.com/tektoncd/triggers/blob/master/docs/eventlisteners.md#event-interceptor-services) for a few releases or until beta.
+    This model [diverges](#http-interface) from the existing WebHookInterceptor model. For backwards compatibility, we can keep supporting the existing [WebhookInterceptor interface](https://github.com/tektoncd/triggers/blob/main/docs/eventlisteners.md#event-interceptor-services) for a few releases or until beta.
 
 4. Secrets and RBAC concerns 
 
@@ -513,7 +513,7 @@ migration strategy. This is especially useful when we modify a
 behavior or add a feature that may replace and deprecate a current one.
 -->
 
-* We'll keep supporting the current [webhook interface](https://github.com/tektoncd/triggers/blob/master/docs/eventlisteners.md#event-interceptor-services) until beta.
+* We'll keep supporting the current [webhook interface](https://github.com/tektoncd/triggers/blob/main/docs/eventlisteners.md#event-interceptor-services) until beta.
 
 ## Work Plan
 

teps/0035-document-tekton-position-around-policy-authentication-authorization.md

@@ -483,8 +483,8 @@ Namespace has sufficient permissions via Kubernetes RBAC to access the `ClusterT
 As mentioned in the Summary, [this Tekton Triggers issue](https://github.com/tektoncd/triggers/issues/610) is the 
 source for raising this scenario here, and has a bunch of good detailed discussion.
 
-In that issue, an approach using the [Tekton Trigger (Custom) Webhook Interceptor](https://github.com/tektoncd/triggers/blob/master/docs/eventlisteners.md#webhook-interceptors)
-could serve as the means to engage with [OPA's support for validating JWT Token (e.g OpenID Connect)](https://github.com/tektoncd/triggers/blob/master/docs/eventlisteners.md#webhook-interceptors)
+In that issue, an approach using the [Tekton Trigger (Custom) Webhook Interceptor](https://github.com/tektoncd/triggers/blob/main/docs/eventlisteners.md#webhook-interceptors)
+could serve as the means to engage with [OPA's support for validating JWT Token (e.g OpenID Connect)](https://github.com/tektoncd/triggers/blob/main/docs/eventlisteners.md#webhook-interceptors)
 to validate whether the user's tokens in incoming HTTP payload can access the referenced Trigger and the Task/TaskRuns etc.
 the Trigger can initiate.