Repository: tektoncd/pipeline (language: go)

Issue:
Deduplicate examples tests between v1 and v1beta1
Currently, we run a large number of examples tests that are duplicated in v1 and v1beta1. These tests are meant to test specific features, such as params and workspaces, that have the same syntax and implementation in v1 and v1beta1. Since we have conversion integration tests, these duplicated examples tests are likely adding little value.

In addition, examples tests are the flakiest set of tests in the repo and often time out. Removing redundant examples tests should make our CI less flaky.

This commit moves any examples tests that were solely present in v1beta1 to v1, leaving only those that use features that weren't migrated to v1. It deletes any examples that were duplicated between v1 and v1beta1.

/kind cleanup
Partially addresses https://github.com/tektoncd/pipeline/issues/6906

# Submitter Checklist

As the author of this PR, please check off the items in this checklist:

- n/a Has [Docs](https://github.com/tektoncd/community/blob/main/standards.md#docs) if any changes are user facing, including updates to minimum requirements e.g. Kubernetes version bumps
- n/a Has [Tests](https://github.com/tektoncd/community/blob/main/standards.md#tests) included if any functionality added or changed
- [x] Follows the [commit message standard](https://github.com/tektoncd/community/blob/main/standards.md#commits)
- [x] Meets the [Tekton contributor standards](https://github.com/tektoncd/community/blob/main/standards.md) (including functionality, content, code)
- [x] Has a kind label. You can add one by adding a comment on this PR that contains `/kind <type>`. Valid types are bug, cleanup, design, documentation, feature, flake, misc, question, tep
- n/a Release notes block below has been updated with any user facing changes (API changes, bug fixes, changes requiring upgrade notices or deprecation warnings). See some examples of [good release notes](https://github.com/tektoncd/community/blob/main/standards.md#good-release-notes).
- n/a Release notes contains the string "action required" if the change requires additional action from users switching to the new release

# Release Notes

```release-note
NONE
```



Discussion / hints:
reading the description of this PR again, you are not actually removing any tests because there are integration tests for the same functionality, you are only deduplicating v1 and v1beta1 -- is that correct? if so, I suggest updating the title to "deduplicate example tests in v1beta1 and v1"

reading https://github.com/tektoncd/pipeline/issues/6906 and the title made me think that you were actually removing tests -- thought the redundancy is with integration tests

please clarify
Thanks for the feedback, updated the PR title and commit message!
[APPROVALNOTIFIER] This PR is **APPROVED**

This pull-request has been approved by: *<a href="https://github.com/tektoncd/pipeline/pull/6908#pullrequestreview-1524138204" title="Approved">jerop</a>*

The full list of commands accepted by this bot can be found [here](https://prow.tekton.dev/command-help?repo=tektoncd%2Fpipeline).

The pull request process is described [here](https://git.k8s.io/community/contributors/guide/owners.md#the-code-review-process)

<details >
Needs approval from an approver in each of these files:

- ~~[OWNERS](https://github.com/tektoncd/pipeline/blob/main/OWNERS)~~ [jerop]

Approvers can indicate their approval by writing `/approve` in a comment
Approvers can cancel approval by writing `/approve cancel` in a comment
</details>
<!-- META={"approvers":[]} -->
/lgtm

Thanks! Not sure if in docs we linked to examples moved in this PR, but should be easy to fix if there is any
/lgtm

Fix patch:
diff --git a/docs/api-spec.md b/docs/api-spec.md
index fa7462c326a..f2fa7954b29 100644
--- a/docs/api-spec.md
+++ b/docs/api-spec.md
@@ -236,7 +236,7 @@ List responses have the following fields (based on [`meta.v1/ListMeta`](https://
 | `name`        | string     | REQUIRED    |
 | `description` | string     | REQUIRED    |
 | `type`      | Enum:<br>- `"string"` (default)<br>- `"array"` <br>- `"object"` | REQUIRED (The values `string` and `array` for this field are REQUIRED, and the value `object` is RECOMMENDED.) |
-| `properties`  | map<string,PropertySpec> |RECOMMENDED <br><br>note: `PropertySpec` is a type that defines the spec of an individual key. See how to define the `properties` section in the [example](../examples/v1beta1/taskruns/alpha/object-param-result.yaml).|
+| `properties`  | map<string,PropertySpec> |RECOMMENDED <br><br>note: `PropertySpec` is a type that defines the spec of an individual key. See how to define the `properties` section in the [example](../examples/v1/taskruns/beta/object-param-result.yaml).|
 | `default`     | `ParamValue` | REQUIRED |
 
 ### `ParamValue`
@@ -276,7 +276,7 @@ A `ParamValue` may be a string, a list of string, or a map of string to string.
 | `name`        | string    | REQUIRED    |
 | `description` | string    | REQUIRED    |
 | `type`      | Enum:<br>- `"string"` (default)<br>- `"array"` <br>- `"object"` | RECOMMENDED (Each of the values is RECOMMENDED.)|
-| `properties`  | map<string,PropertySpec> | RECOMMENDED <br><br>note: `PropertySpec` is a type that defines the spec of an individual key. See how to define the `properties` section in the [example](../examples/v1beta1/taskruns/alpha/object-param-result.yaml).|
+| `properties`  | map<string,PropertySpec> | RECOMMENDED <br><br>note: `PropertySpec` is a type that defines the spec of an individual key. See how to define the `properties` section in the [example](../examples/v1/taskruns/beta/object-param-result.yaml).|
 
 ### `TaskRunResult`
 
diff --git a/docs/auth.md b/docs/auth.md
index e389b2bf42b..10a68fa4d0e 100644
--- a/docs/auth.md
+++ b/docs/auth.md
@@ -137,7 +137,7 @@ The following are considerations for executing `Runs` as a non-root user:
   the non-root user's valid home directory to use SSH authentication for either Git or Docker.
 
 For an example of configuring SSH authentication in a non-root `securityContext`,
-see [`authenticating-git-commands`](../examples/v1beta1/taskruns/authenticating-git-commands.yaml).
+see [`authenticating-git-commands`](../examples/v1/taskruns/authenticating-git-commands.yaml).
 
 ## Limiting `Secret` access to specific `Steps`
 
@@ -336,7 +336,7 @@ to the home directory of its associated user.
 **Note:** This explicit symlinking is not necessary when using the
 [`git-clone` `Task`](https://github.com/tektoncd/catalog/tree/v1beta1/git) from Tekton Catalog.
 
-For example usage, see [`authenticating-git-commands`](../examples/v1beta1/taskruns/authenticating-git-commands.yaml).
+For example usage, see [`authenticating-git-commands`](../examples/v1/taskruns/authenticating-git-commands.yaml).
 
 ## Configuring authentication for Docker
 
diff --git a/docs/developers/api-versioning.md b/docs/developers/api-versioning.md
index 00048e7392e..fcde31a7590 100644
--- a/docs/developers/api-versioning.md
+++ b/docs/developers/api-versioning.md
@@ -86,12 +86,12 @@ if err := ts.TestThing(ctx); err != nil {
 
 Writing new YAML examples that require a feature gate to be set is easy. New
 YAML example files typically go in a directory called something like
-`examples/v1beta1/taskruns` in the root of the repo. To create a YAML that
+`examples/v1/taskruns` in the root of the repo. To create a YAML that
 should only be exercised when the `enable-api-fields` flag is `alpha` just put
 it in an `alpha` subdirectory so the structure looks like:
 
 ```
-examples/v1beta1/taskruns/alpha/your-example.yaml
+examples/v1/taskruns/alpha/your-example.yaml
 ```
 
 This should work for both taskruns and pipelineruns.
diff --git a/docs/matrix.md b/docs/matrix.md
index 9727bc525c5..89ce63451ad 100644
--- a/docs/matrix.md
+++ b/docs/matrix.md
@@ -850,6 +850,6 @@ status:
 ```
 
 [cel]: https://github.com/tektoncd/experimental/tree/1609827ea81d05c8d00f8933c5c9d6150cd36989/cel
-[pr-with-matrix]: ../examples/v1beta1/pipelineruns/alpha/pipelinerun-with-matrix.yaml
-[pr-with-matrix-and-results]: ../examples/v1beta1/pipelineruns/alpha/pipelinerun-with-matrix-and-results.yaml
+[pr-with-matrix]: ../examples/v1/pipelineruns/alpha/pipelinerun-with-matrix.yaml
+[pr-with-matrix-and-results]: ../examples/v1/pipelineruns/alpha/pipelinerun-with-matrix-and-results.yaml
 [retries]: pipelines.md#using-the-retries-field
diff --git a/docs/pipelineruns.md b/docs/pipelineruns.md
index 7ceab1c9517..84f753a806a 100644
--- a/docs/pipelineruns.md
+++ b/docs/pipelineruns.md
@@ -104,7 +104,7 @@ spec:
           name: mytask
 ```
 
-The `Pipeline` in the [`pipelineSpec` example](../examples/v1beta1/pipelineruns/pipelinerun-with-pipelinespec.yaml)
+The `Pipeline` in the [`pipelineSpec` example](../examples/v1/pipelineruns/pipelinerun-with-pipelinespec.yaml)
 example displays morning and evening greetings. Once you create and execute it, you can check the logs for its `Pods`:
 
 ```bash
@@ -126,7 +126,7 @@ spec:
           steps: ...
 ```
 
-In the [`taskSpec` in `pipelineSpec` example](../examples/v1beta1/pipelineruns/pipelinerun-with-pipelinespec-and-taskspec.yaml)
+In the [`taskSpec` in `pipelineSpec` example](../examples/v1/pipelineruns/pipelinerun-with-pipelinespec-and-taskspec.yaml)
 it's `Tasks` all the way down!
 
 You can also specify labels and annotations with `taskSpec` which are propagated to each `taskRun` and then to the
@@ -976,7 +976,7 @@ spec:
 For more information, see the following topics:
 - For information on mapping `Workspaces` to `Volumes`, see [Specifying `Workspaces` in `PipelineRuns`](workspaces.md#specifying-workspaces-in-pipelineruns).
 - For a list of supported `Volume` types, see [Specifying `VolumeSources` in `Workspaces`](workspaces.md#specifying-volumesources-in-workspaces).
-- For an end-to-end example, see [`Workspaces` in a `PipelineRun`](../examples/v1beta1/pipelineruns/workspaces.yaml).
+- For an end-to-end example, see [`Workspaces` in a `PipelineRun`](../examples/v1/pipelineruns/workspaces.yaml).
 
 [`Custom tasks`](pipelines.md#using-custom-tasks) may or may not use workspaces.
 Consult the documentation of the custom task that you are using to determine whether it supports workspaces.
diff --git a/docs/pipelines.md b/docs/pipelines.md
index 549370f99ff..eff30cd3cd5 100644
--- a/docs/pipelines.md
+++ b/docs/pipelines.md
@@ -182,7 +182,7 @@ spec:
 
 For more information, see:
 - [Using `Workspaces` in `Pipelines`](workspaces.md#using-workspaces-in-pipelines)
-- The [`Workspaces` in a `PipelineRun`](../examples/v1beta1/pipelineruns/workspaces.yaml) code example
+- The [`Workspaces` in a `PipelineRun`](../examples/v1/pipelineruns/workspaces.yaml) code example
 - The [variables available in a `PipelineRun`](variables.md#variables-available-in-a-pipeline), including `workspaces.<name>.bound`.
 - [Mapping `Workspaces`](https://github.com/tektoncd/community/blob/main/teps/0108-mapping-workspaces.md)
 
@@ -612,7 +612,7 @@ tasks:
       name: deployment
 ```
 
-For an end-to-end example, see [PipelineRun with `when` expressions](../examples/v1beta1/pipelineruns/pipelinerun-with-when-expressions.yaml).
+For an end-to-end example, see [PipelineRun with `when` expressions](../examples/v1/pipelineruns/pipelinerun-with-when-expressions.yaml).
 
 There are a lot of scenarios where `when` expressions can be really useful. Some of these are:
 - Checking if the name of a git branch matches
@@ -866,7 +866,7 @@ performed by the Tekton Controller when a PipelineRun is executed.
 See the [complete list of variable substitutions for Pipelines](./variables.md#variables-available-in-a-pipeline)
 and the [list of fields that accept substitutions](./variables.md#fields-that-accept-variable-substitutions).
 
-For an end-to-end example, see [using context variables](../examples/v1beta1/pipelineruns/using_context_variables.yaml).
+For an end-to-end example, see [using context variables](../examples/v1/pipelineruns/using_context_variables.yaml).
 
 ### Using the `retries` and `retry-count` variable substitutions
 
@@ -966,7 +966,7 @@ when:
     values: ["yes"]
 ```
 
-For an end-to-end example, see [`Task` `Results` in a `PipelineRun`](../examples/v1beta1/pipelineruns/task_results_example.yaml).
+For an end-to-end example, see [`Task` `Results` in a `PipelineRun`](../examples/v1/pipelineruns/task_results_example.yaml).
 
 Note that `when` expressions are whitespace-sensitive.  In particular, when producing results intended for inputs to `when`
 expressions that may include newlines at their close (e.g. `cat`, `jq`), you may wish to truncate them.
@@ -1007,10 +1007,10 @@ results:
     value: $(tasks.calculate-sum.results.outputValue)
 ```
 
-For an end-to-end example, see [`Results` in a `PipelineRun`](../examples/v1beta1/pipelineruns/pipelinerun-results.yaml).
+For an end-to-end example, see [`Results` in a `PipelineRun`](../examples/v1/pipelineruns/pipelinerun-results.yaml).
 
 Object result and array result are beta features,
-see [`Array and Object Results` in a `PipelineRun`](../examples/v1beta1/pipelineruns/beta/pipeline-emitting-results.yaml).
+see [`Array and Object Results` in a `PipelineRun`](../examples/v1/pipelineruns/beta/pipeline-emitting-results.yaml).
 
 ```yaml
     results:
@@ -1347,7 +1347,7 @@ This kind of variable can have any one of the values from the following table:
 | `Failed`    | `taskRun` for the `pipelineTask` completed with a failure or cancelled by the user               |
 | `None`      | the `pipelineTask` has been skipped or no execution information available for the `pipelineTask` |
 
-For an end-to-end example, see [`status` in a `PipelineRun`](../examples/v1beta1/pipelineruns/pipelinerun-task-execution-status.yaml).
+For an end-to-end example, see [`status` in a `PipelineRun`](../examples/v1/pipelineruns/pipelinerun-task-execution-status.yaml).
 
 ### Using Aggregate Execution `Status` of All `Tasks`
 
@@ -1381,7 +1381,7 @@ This kind of variable can have any one of the values from the following table:
 | `Completed` | all `tasks` completed successfully including one or more skipped tasks                                                            |
 | `None`      | no aggregate execution status available (i.e. none of the above), one or more `tasks` could be pending/running/cancelled/timedout |
 
-For an end-to-end example, see [`$(tasks.status)` usage in a `Pipeline`](../examples/v1beta1/pipelineruns/pipelinerun-task-execution-status.yaml).
+For an end-to-end example, see [`$(tasks.status)` usage in a `Pipeline`](../examples/v1/pipelineruns/pipelinerun-task-execution-status.yaml).
 
 ### Guard `finally` `Task` execution using `when` expressions
 
@@ -1494,7 +1494,7 @@ spec:
       # […]
 ```
 
-For an end-to-end example, see [PipelineRun with `when` expressions](../examples/v1beta1/pipelineruns/pipelinerun-with-when-expressions.yaml).
+For an end-to-end example, see [PipelineRun with `when` expressions](../examples/v1/pipelineruns/pipelinerun-with-when-expressions.yaml).
 
 #### `when` expressions using `Aggregate Execution Status` of `Tasks` in `finally` `tasks`
 
@@ -1512,7 +1512,7 @@ finally:
       name: notify-failure
 ```
 
-For an end-to-end example, see [PipelineRun with `when` expressions](../examples/v1beta1/pipelineruns/pipelinerun-with-when-expressions.yaml).
+For an end-to-end example, see [PipelineRun with `when` expressions](../examples/v1/pipelineruns/pipelinerun-with-when-expressions.yaml).
 
 ### Known Limitations
 
diff --git a/docs/taskruns.md b/docs/taskruns.md
index d12bc657f07..6adf51e2bdb 100644
--- a/docs/taskruns.md
+++ b/docs/taskruns.md
@@ -501,7 +501,7 @@ workspaces:
 For more information, see the following topics:
 - For information mapping `Workspaces` to `Volumes`, see [Using `Workspace` variables in `TaskRuns`](workspaces.md#using-workspace-variables-in-taskruns).
 - For a list of supported `Volume` types, see [Specifying `VolumeSources` in `Workspaces`](workspaces.md#specifying-volumesources-in-workspaces).
-- For an end-to-end example, see [`Workspaces` in a `TaskRun`](../examples/v1beta1/taskruns/workspace.yaml).
+- For an end-to-end example, see [`Workspaces` in a `TaskRun`](../examples/v1/taskruns/workspace.yaml).
 
 #### Propagated Workspaces
 
@@ -1091,7 +1091,7 @@ spec:
 
 If a Task step specifies that it is to run as a different user than what is specified in the pod template,
 the step's `securityContext` will be applied instead of what is specified at the pod level. An example of
-this is available as a [TaskRun example](../examples/v1beta1/taskruns/run-steps-as-non-root.yaml).
+this is available as a [TaskRun example](../examples/v1/taskruns/run-steps-as-non-root.yaml).
 
 More information about Pod and Container Security Contexts can be found via the [Kubernetes website](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod).
 
diff --git a/docs/tasks.md b/docs/tasks.md
index e193355d009..f576bd91171 100644
--- a/docs/tasks.md
+++ b/docs/tasks.md
@@ -429,8 +429,8 @@ kubectl get tr taskrun-unit-test-t6qcl -o json | jq .status
   ],
 ```
 
-For an end-to-end example, see [the taskRun ignoring a step error](../examples/v1beta1/taskruns/ignore-step-error.yaml)
-and [the pipelineRun ignoring a step error](../examples/v1beta1/pipelineruns/ignore-step-error.yaml).
+For an end-to-end example, see [the taskRun ignoring a step error](../examples/v1/taskruns/ignore-step-error.yaml)
+and [the pipelineRun ignoring a step error](../examples/v1/pipelineruns/ignore-step-error.yaml).
 
 #### Accessing Step's `exitCode` in subsequent `Steps`
 
@@ -588,13 +588,13 @@ spec:
           type: string
 ```
 
-Refer to the [TaskRun example](../examples/v1beta1/taskruns/alpha/object-param-result.yaml) and the [PipelineRun example](../examples/v1beta1/pipelineruns/alpha/pipeline-object-param-and-result.yaml) in which `object` parameters are demonstrated.
+Refer to the [TaskRun example](../examples/v1/taskruns/beta/object-param-result.yaml) and the [PipelineRun example](../examples/v1/pipelineruns/beta/pipeline-object-param-and-result.yaml) in which `object` parameters are demonstrated.
 
   > NOTE:
   > - `object` param is a `beta` feature and gated by the `alpha` or `beta` feature flag.
   > - `object` param must specify the `properties` section to define the schema i.e. what keys are available for this object param. See how to define `properties` section in the following example and the [TEP-0075](https://github.com/tektoncd/community/blob/main/teps/0075-object-param-and-result-types.md#defaulting-to-string-types-for-values).
-  > - When providing value for an `object` param, one may provide values for just a subset of keys in spec's `default`, and provide values for the rest of keys at runtime ([example](../examples/v1beta1/taskruns/beta/object-param-result.yaml)).
-  > - When using object in variable replacement, users can only access its individual key ("child" member) of the object by its name i.e. `$(params.gitrepo.url)`. Using an entire object as a value is only allowed when the value is also an object like [this example](https://github.com/tektoncd/pipeline/blob/55665765e4de35b3a4fb541549ae8cdef0996641/examples/v1beta1/pipelineruns/beta/pipeline-object-param-and-result.yaml#L64-L65). See more details about using object param from the [TEP-0075](https://github.com/tektoncd/community/blob/main/teps/0075-object-param-and-result-types.md#using-objects-in-variable-replacement).
+  > - When providing value for an `object` param, one may provide values for just a subset of keys in spec's `default`, and provide values for the rest of keys at runtime ([example](../examples/v1/taskruns/beta/object-param-result.yaml)).
+  > - When using object in variable replacement, users can only access its individual key ("child" member) of the object by its name i.e. `$(params.gitrepo.url)`. Using an entire object as a value is only allowed when the value is also an object like [this example](https://github.com/tektoncd/pipeline/blob/55665765e4de35b3a4fb541549ae8cdef0996641/examples/v1/pipelineruns/beta/pipeline-object-param-and-result.yaml#L64-L65). See more details about using object param from the [TEP-0075](https://github.com/tektoncd/community/blob/main/teps/0075-object-param-and-result-types.md#using-objects-in-variable-replacement).
 
 ##### `array` type
 
@@ -694,7 +694,7 @@ spec:
 #### Default value
 Parameter declarations (within Tasks and Pipelines) can include default values which will be used if the parameter is
 not specified, for example to specify defaults for both string params and array params
-([full example](../examples/v1beta1/taskruns/array-default.yaml)) :
+([full example](../examples/v1/taskruns/array-default.yaml)) :
 
 ```yaml
 apiVersion: tekton.dev/v1 # or tekton.dev/v1beta1
@@ -734,7 +734,7 @@ spec:
 ```
 
 For more information, see [Using `Workspaces` in `Tasks`](workspaces.md#using-workspaces-in-tasks)
-and the [`Workspaces` in a `TaskRun`](../examples/v1beta1/taskruns/workspace.yaml) example YAML file.
+and the [`Workspaces` in a `TaskRun`](../examples/v1/taskruns/workspace.yaml) example YAML file.
 
 ### Propagated `Workspaces`
 
@@ -1542,7 +1542,7 @@ specified at the pod level via the TaskRun `podTemplate`.
 
 More information about Pod and Container Security Contexts can be found via the [Kubernetes website](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod).
 
-The example Task/TaskRun above can be found as a [TaskRun example](../examples/v1beta1/taskruns/run-steps-as-non-root.yaml).
+The example Task/TaskRun above can be found as a [TaskRun example](../examples/v1/taskruns/run-steps-as-non-root.yaml).
 
 ## `Task` Authoring Recommendations
 
diff --git a/docs/workspaces.md b/docs/workspaces.md
index 87c6637e2cf..24a7dec2797 100644
--- a/docs/workspaces.md
+++ b/docs/workspaces.md
@@ -311,7 +311,7 @@ spec:
                         # but consider using a PersistentVolumeClaim for PipelineRuns
 ```
 For examples of using other types of volume sources, see [Specifying `VolumeSources` in `Workspaces`](#specifying-volumesources-in-workspaces).
-For a more in-depth example, see [`Workspaces` in a `TaskRun`](../examples/v1beta1/taskruns/workspace.yaml).
+For a more in-depth example, see [`Workspaces` in a `TaskRun`](../examples/v1/taskruns/workspace.yaml).
 
 ### Using `Workspaces` in `Pipelines`
 
@@ -353,7 +353,7 @@ spec:
         - use-ws-from-pipeline # important: use-ws-from-pipeline writes to the workspace first
 ```
 
-Include a `subPath` in the `Workspace Binding` to mount different parts of the same volume for different Tasks. See [a full example of this kind of Pipeline](../examples/v1beta1/pipelineruns/pipelinerun-using-different-subpaths-of-workspace.yaml) which writes data to two adjacent directories on the same Volume.
+Include a `subPath` in the `Workspace Binding` to mount different parts of the same volume for different Tasks. See [a full example of this kind of Pipeline](../examples/v1/pipelineruns/pipelinerun-using-different-subpaths-of-workspace.yaml) which writes data to two adjacent directories on the same Volume.
 
 The `subPath` specified in a `Pipeline` will be appended to any `subPath` specified as part of the `PipelineRun` workspace declaration. So a `PipelineRun` declaring a `Workspace` with `subPath` of `/foo` for a `Pipeline` who binds it to a `Task` with `subPath` of `/bar` will end up mounting the `Volume`'s `/foo/bar` directory.
 
@@ -433,7 +433,7 @@ spec:
 ```
 
 For examples of using other types of volume sources, see [Specifying `VolumeSources` in `Workspaces`](#specifying-volumesources-in-workspaces).
-For a more in-depth example, see the [`Workspaces` in `PipelineRun`](../examples/v1beta1/pipelineruns/workspaces.yaml) YAML sample.
+For a more in-depth example, see the [`Workspaces` in `PipelineRun`](../examples/v1/pipelineruns/workspaces.yaml) YAML sample.
 
 ### Specifying `VolumeSources` in `Workspaces`
 
@@ -568,7 +568,7 @@ Example of CSI workspace using Hashicorp Vault:
 - Install the required csi driver. eg. [secrets-store-csi-driver](https://github.com/hashicorp/vault-csi-provider#using-yaml)
 - Install the `vault` Provider onto the kubernetes cluster. [Reference](https://learn.hashicorp.com/tutorials/vault/kubernetes-raft-deployment-guide)
 - Deploy a provider via [example](https://gist.github.com/JeromeJu/cc8e4e758029b6694806604750b8911c)
-- Create a SecretProviderClass Provider using the following [yaml](https://github.com/tektoncd/pipeline/blob/main/examples/v1beta1/pipelineruns/no-ci/csi-workspace.yaml#L1-L19)
+- Create a SecretProviderClass Provider using the following [yaml](https://github.com/tektoncd/pipeline/blob/main/examples/v1/pipelineruns/no-ci/csi-workspace.yaml#L1-L19)
 - Specify the ServiceAccount via vault:
 
 ```
@@ -626,6 +626,6 @@ the storage solution that you are using.
 
 See the following in-depth examples of configuring `Workspaces`:
 
-- [`Workspaces` in a `TaskRun`](../examples/v1beta1/taskruns/workspace.yaml)
-- [`Workspaces` in a `PipelineRun`](../examples/v1beta1/pipelineruns/workspaces.yaml)
-- [`Workspaces` from a volumeClaimTemplate in a `PipelineRun`](../examples/v1beta1/pipelineruns/workspace-from-volumeclaimtemplate.yaml)
+- [`Workspaces` in a `TaskRun`](../examples/v1/taskruns/workspace.yaml)
+- [`Workspaces` in a `PipelineRun`](../examples/v1/pipelineruns/workspaces.yaml)
+- [`Workspaces` from a volumeClaimTemplate in a `PipelineRun`](../examples/v1/pipelineruns/workspace-from-volumeclaimtemplate.yaml)


Test patch: