Update pipeline reference from master to main 🧙

roadmap.md

@@ -5,7 +5,7 @@ This doc describes Tekton's mission and the 2020 roadmap.
 - [Mission and Vision](#mission-and-vision)
 - [2021 Roadmap](#2021-roadmap)
 - Tekton Project Roadmaps
-  - [Pipeline](https://github.com/tektoncd/pipeline/blob/master/roadmap.md)
+  - [Pipeline](https://github.com/tektoncd/pipeline/blob/main/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/main/roadmap.md)
@@ -61,4 +61,4 @@ result in the creation of new projects!
   * Documentation, tools, examples for how to handle specific problems using Tekton
     * Best practice getting started example repo(s)
     * E.g. being able to answer questions like “I want to setup a CI pipeline for my repo using Tekton,
-      how do I do that in two steps?”
+      how do I do that in two steps?”

standards.md

@@ -117,7 +117,7 @@ _See also [the Tekton review process](https://github.com/tektoncd/community/blob
       it would make sense to move the test into another package and export it
 * Test code
   * When using cmp.Diff the argument order is always (want, got) and in the error message include (-want +got)
-    (and/or use a lib like [PrintWantGot](https://github.com/tektoncd/pipeline/blob/master/test/diff/print.go))
+    (and/or use a lib like [PrintWantGot](https://github.com/tektoncd/pipeline/blob/main/test/diff/print.go))
   * Table driven tests: do not use the same test for success and fail cases if the logic is different
     (e.g. do not have two sets of test logic, gated with `wantErr`)
 

teps/0001-tekton-enhancement-proposal-process.md

@@ -409,7 +409,7 @@ We are now switching to the "Implementing Tekton Bundles" TEP.
 See the following links for more context on this feature:
 
 - [Tekton Pipeline Resource Extensibility](https://docs.google.com/document/d/1rcMG1cIFhhixMSmrT734MBxvH3Ghre9-4S2wbzodPiU/edit#)
-- [Why Aren't PipelineResources in Beta ?](https://github.com/tektoncd/pipeline/blob/master/docs/resources.md#why-arent-pipelineresources-in-beta)
+- [Why Aren't PipelineResources in Beta ?](https://github.com/tektoncd/pipeline/blob/main/docs/resources.md#why-arent-pipelineresources-in-beta)
 - [Pipeline Reosurces Redesign](https://github.com/tektoncd/pipeline/issues/1673)
 
 1. A TEP is proposed to add extensibility to PipelineResources. This

teps/0007-conditions-beta.md

@@ -56,7 +56,7 @@ Original Design Doc in Google Docs, visible to members of tekton-dev@: https://d
 
 ## Summary
 
-`Conditions` is a [CRD](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) used to specify a criteria to determine whether or not a `Task` executes. When other Tekton resources were migrated to [beta](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#alpha-beta-and-ga), it remained in [alpha](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md#alpha-beta-and-ga) because it was missing features needed by users.
+`Conditions` is a [CRD](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) used to specify a criteria to determine whether or not a `Task` executes. When other Tekton resources were migrated to [beta](https://github.com/tektoncd/pipeline/blob/main/api_compatibility_policy.md#alpha-beta-and-ga), it remained in [alpha](https://github.com/tektoncd/pipeline/blob/main/api_compatibility_policy.md#alpha-beta-and-ga) because it was missing features needed by users.
 
 After analyzing the feature requests and discussing with users, we have identified that the most critical gaps in `Conditions` are **simplicity**, **efficiency**, **skipping** and **status**. We want to address these gaps so that it can work well with the other `Pipeline` resources and users can count on its stability.
 

teps/0021-results-api.md

@@ -685,7 +685,7 @@ needs.
 ### Naming overlap with Task results
 
 There is naming overlap with
-[Task outputs](https://github.com/tektoncd/pipeline/blob/master/docs/tasks.md#emitting-results),
+[Task outputs](https://github.com/tektoncd/pipeline/blob/main/docs/tasks.md#emitting-results),
 called Task results. There is a risk that users may confuse Tekton Results with
 Task results.
 
@@ -731,7 +731,7 @@ behavior or add a feature that may replace and deprecate a current one.
 -->
 
 We will be consistent with the Pipelines
-[API compatibility policy](https://github.com/tektoncd/pipeline/blob/master/api_compatibility_policy.md) -
+[API compatibility policy](https://github.com/tektoncd/pipeline/blob/main/api_compatibility_policy.md) -
 tl;dr free to make breaking changes in alpha, breaking changes are allowed with
 a deprecation period in beta, and no breaking changes allowed in stable (i.e.
 v1).

teps/0024-embedded-trigger-templates.md

@@ -33,7 +33,7 @@ resources makes it simple (and less verbose) to express workflows in Tekton.
 This is especially true for simple use cases, examples, and documentation where
 reusability is less of a concern. For instance, Task specs can be embedded
 inside TaskRuns (see the
-[examples](https://github.com/tektoncd/pipeline/tree/master/examples/v1beta1/taskruns)).
+[examples](https://github.com/tektoncd/pipeline/tree/main/examples/v1beta1/taskruns)).
 
 Within a Trigger, at the moment, only `bindings` can be embedded while Templates
 always have to be referenced. Allowing embedded templates will make it easier

teps/0028-task-execution-status-at-runtime.md

@@ -102,7 +102,7 @@ All necessary e2e and unit tests will be added.
 ## Alternatives
 
 * If the states defined in this [Proposal](#proposal) are not clear, one alternative is to change these states and align them
-to `pipelineRun` [execution status](https://github.com/tektoncd/pipeline/blob/master/docs/pipelineruns.md#monitoring-execution-status) (`Unknown`, `True`, `False`). Also change the proposed variable pattern to match these states.
+to `pipelineRun` [execution status](https://github.com/tektoncd/pipeline/blob/main/docs/pipelineruns.md#monitoring-execution-status) (`Unknown`, `True`, `False`). Also change the proposed variable pattern to match these states.
 
 * Another alternative is to add more states such as `Started`, `Running`, and `Cancelled` if the proposed states are
 not sufficient for your use cases.

teps/0029-step-workspaces.md

@@ -220,7 +220,7 @@ of a temporary `authorized_keys` file which in turn allows the Steps to successf
 the Sidecar over SSH.
 
 For an existing example where this could be useful, see the
-[authenticating-git-commands](https://github.com/tektoncd/pipeline/blob/master/examples/v1beta1/taskruns/authenticating-git-commands.yaml)
+[authenticating-git-commands](https://github.com/tektoncd/pipeline/blob/main/examples/v1beta1/taskruns/authenticating-git-commands.yaml)
 example from the Pipelines repo.
 
 #### Story 4

teps/0030-workspace-paths.md

@@ -147,7 +147,7 @@ workspace. Here's an example from our catalog:
 _and_ the files that are expected to be received on them. Example from
 [recent `tkn` PR](https://github.com/tektoncd/catalog/pull/499/files#diff-6752c482b505c3f8ffed15a7d7d291b5R20-R23):
 
-    > - **kubeconfig**: An [optional workspace](https://github.com/tektoncd/pipeline/blob/master/docs/workspaces.md#using-workspaces-in-tasks)
+    > - **kubeconfig**: An [optional workspace](https://github.com/tektoncd/pipeline/blob/main/docs/workspaces.md#using-workspaces-in-tasks)
     > that allows you to provide a `.kube/config` file for `tkn` to access the cluster.
     > The file should be placed at the root of the Workspace with name `kubeconfig`.
 

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

@@ -79,7 +79,7 @@ if need be and bring it up.
 
 ## Motivation
 
-As noted at the top of the [Tekton Pipelines README.md](https://github.com/tektoncd/pipeline/blob/master/README.md),
+As noted at the top of the [Tekton Pipelines README.md](https://github.com/tektoncd/pipeline/blob/main/README.md),
 the first of its main, high level, advantages is that Tekton is Cloud Native, implemented as Kubernetes, and thus
 inherently has the ability to integrate into key Kubernetes facilities around:
 
@@ -167,13 +167,13 @@ there are sufficient third party solutions we can work with in order to meet tho
 
 ## Proposal
 
-We augment documentation, much like what exists [for Authentication](https://github.com/tektoncd/pipeline/blob/master/docs/auth.md)
+We augment documentation, much like what exists [for Authentication](https://github.com/tektoncd/pipeline/blob/main/docs/auth.md)
 for the other typical security concerns.  Here is a current sampling of scenarios, where of course this is a moment in time snapshot,
 and perhaps not even a complete one at that (we can grow documentation iteratively of course):
 
 ### Pod Security Policy (PSP)
 
-Providing some concise background / and or details on why [the current Pod Security Policy](https://github.com/tektoncd/pipeline/blob/master/config/101-podsecuritypolicy.yaml)
+Providing some concise background / and or details on why [the current Pod Security Policy](https://github.com/tektoncd/pipeline/blob/main/config/101-podsecuritypolicy.yaml)
 has what it has could prove helpful to new users.
 
 Perhaps mine the PRs associated with the history of changes.  Avoid simply repeating k8s documentation for the fields.

teps/0037-remove-gcs-fetcher.md

@@ -23,7 +23,7 @@ status: implementing
 
 ## Summary
 
-Every Tekton Pipelines release builds and bundles an image, `gcs-fetcher`, which is vendored from https://github.com/GoogleCloudPlatform/cloud-builders/blob/master/gcs-fetcher. This image exists to support the [BuildGCS Storage Resource](https://github.com/tektoncd/pipeline/blob/master/docs/resources.md#buildgcs-storage-resource). That is, the image is involved when the user configures a `storage`-type `PipelineResource`, with a `type` of `build-gcs`.
+Every Tekton Pipelines release builds and bundles an image, `gcs-fetcher`, which is vendored from https://github.com/GoogleCloudPlatform/cloud-builders/blob/master/gcs-fetcher. This image exists to support the [BuildGCS Storage Resource](https://github.com/tektoncd/pipeline/blob/main/docs/resources.md#buildgcs-storage-resource). That is, the image is involved when the user configures a `storage`-type `PipelineResource`, with a `type` of `build-gcs`.
 
 Tekton Pipelines doesn't collect centralized usage metrics, but I personally believe this functionality is not used. If it _is_ used, the only functionality it provides beyond the `gcs`-type `PipelineResource` is in supporting [Source Manifests](https://github.com/GoogleCloudPlatform/cloud-builders/tree/master/gcs-fetcher#source-manifests), which I believe nobody does today.
 
@@ -35,7 +35,7 @@ I would like to remove support for the `build-gcs` `PipelineResource`.
 
 Building and releasing an image in Tekton's core upstream repo induces release and maintenance burden on all downstream teams. So far this burden has been relatively light, but nobody knows when you might find a critical CVE or crashing bug in unused legacy behavior.
 
-Support for the `build-gcs` `PipelineResource` was added to ease the transition of [Knative Build](https://github.com/knative/build) users [migrating to Tekton Pipelines](https://github.com/tektoncd/pipeline/blob/master/docs/migrating-from-knative-build.md). I believe Source Manifest usage was low even back when Knative Build was a thing, let alone nearly eighteen months later.
+Support for the `build-gcs` `PipelineResource` was added to ease the transition of [Knative Build](https://github.com/knative/build) users [migrating to Tekton Pipelines](https://github.com/tektoncd/pipeline/blob/main/docs/migrating-from-knative-build.md). I believe Source Manifest usage was low even back when Knative Build was a thing, let alone nearly eighteen months later.
 
 Given the assumption of low utility and non-zero cost, and the potential of higher future cost, we should bias toward action in removing support.
 
@@ -55,7 +55,7 @@ This proposal does not intend to remove support for the `gcs`-type `PipelineReso
 
 When this proposal is marked `implementing`, attempt to notify Tekton users and operators to let them know the deprecation is coming, and ask for feedback. This includes posting to `tekton-users@`, the Tekton Slack, weekly WG meetings, and, if need be, me personally shouting it from my balcony.
 
-Assuming no negative response from that communication, update [the docs](https://github.com/tektoncd/pipeline/blob/master/docs/resources.md#gcs-storage-resource) to note that support will be deprecated in the next release (currently, v1.21).
+Assuming no negative response from that communication, update [the docs](https://github.com/tektoncd/pipeline/blob/main/docs/resources.md#gcs-storage-resource) to note that support will be deprecated in the next release (currently, v1.21).
 
 Assuming no negative response, after the v1.21 release branch is cut, remove support for `build-crd` and remove `gcs-fetcher` from the Tekton Pipelines codebase.