docs: Update references to examples from v1beta1 to v1

In response to the cleanup effort aimed at deduplicating tests between v1 and v1beta1,
this commit addresses broken links in our documentation. The changes involve updating
references to examples under the v1beta1 API version to instead point to the v1 API version.
Additionally, certain features that transitioned from alpha to beta within the v1 API required
corresponding updates to their references.

This change ensures that the documentation accurately reflects the current state of the project,
eliminating broken links and inconsistencies. The goal is to improve the overall user experience
and provide accurate information.

Fixes #6908

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`
 

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
 

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.

docs/matrix.md

@@ -849,6 +849,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

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.

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)
 
@@ -609,7 +609,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
@@ -863,7 +863,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
 
@@ -961,7 +961,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.
@@ -1002,10 +1002,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:
@@ -1339,7 +1339,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`
 
@@ -1373,7 +1373,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
 
@@ -1486,7 +1486,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`
 
@@ -1504,7 +1504,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
 

docs/taskruns.md

@@ -501,7 +501,7 @@ workspaces:
 For more information, see the following topics:
 - For information on 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
 
@@ -1092,7 +1092,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).
 

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