Remove deprecated Conditions CRD/functionality

cmd/webhook/main.go

@@ -51,7 +51,6 @@ var types = map[schema.GroupVersionKind]resourcesemantics.GenericCRD{
 	v1alpha1.SchemeGroupVersion.WithKind("ClusterTask"):      &v1alpha1.ClusterTask{},
 	v1alpha1.SchemeGroupVersion.WithKind("TaskRun"):          &v1alpha1.TaskRun{},
 	v1alpha1.SchemeGroupVersion.WithKind("PipelineRun"):      &v1alpha1.PipelineRun{},
-	v1alpha1.SchemeGroupVersion.WithKind("Condition"):        &v1alpha1.Condition{},
 	v1alpha1.SchemeGroupVersion.WithKind("PipelineResource"): &v1alpha1.PipelineResource{},
 	v1alpha1.SchemeGroupVersion.WithKind("Run"):              &v1alpha1.Run{},
 	// v1beta1

docs/conditions.md

@@ -6,99 +6,7 @@ weight: 2100
 -->
 # Conditions
 
-**Note:** `Conditions` are deprecated, use [`when` expressions](pipelines.md#guard-task-execution-using-when-expressions) instead. 
-
-- [Overview](#overview)
-- [Configuring a `Condition`](#configuring-a-condition)
-  - [Specifying the condition `check`](#specifying-the-condition-check)
-  - [Specifying `Parameters`](#specifying-parameters)
-  - [Specifying `Resources`](#specifying-resources)
-- [Code examples](#code-examples)
-
-## Overview
-
-A `Condition` resource in Tekton allows you to conditionalize the execution of `Tasks` within a `Pipeline`.
-You define each `Condition` within your [`PipelineRun` definition](pipelineruns.md) and then conditionalize
-each desired [`Task`](tasks.md) in the corresponding `Pipeline` definition. 
-
-The `Condition` resource runs its own container image that executes the logic that evaluates your chosen condition.
-This container runs to completion and must return an exit code value of `0` for the `check` to be successful; otherwise
-the conditionalized `Task` as well as its `Task` dependencies (defined via `runAfter`) and `Resource` dependencies
-(such as results) do not execute.
-
-**Note:** [Labels](labels.md) and annotations specified in the `Condition's` metadata are automatically
-propagated to the `Pod`.
-
-## Configuring a `Condition`
-
-A `Condition` definition supports the following fields:
-
-- Required:
-  - [`apiVersion`][kubernetes-overview] - Specifies the API version, for example
-    `tekton.dev/v1alpha1`.
-  - [`kind`][kubernetes-overview] - Identifies this resource object as a `Condition` object.
-  - [`metadata`][kubernetes-overview] - Specifies metadata that uniquely identifies this
-    `Condition` object. For example, a `name`.
-  - [`spec`][kubernetes-overview] - Specifies the configuration information for
-    this `Condition` resource object. This must include:
-    - [`check`](#check) - Specifies a container that you want to run for evaluating this `Condition`.
-    - [`description`](#description) - Provides a meaningful description of this `Condition` object.
-
-[kubernetes-overview]:
-  https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/#required-fields
-
-### Specifying the condition `check` 
-
-The `check` field (required) specifies a single piece of evaluation logic that you want to run before the
-corresponding `Task` in your `Pipeline` can execute. This field must specify a [`Step`](./tasks.md#steps). 
-
-### Specifying `Parameters`
-
-You can specify parameters to pass to the `Condition's` evaluation logic at run time. 
-Sub-fields within the `check` field can access these parameter values using Tekton's templating
-syntax as follows:
-
-```yaml
-spec:
-  parameters:
-    - name: image
-      default: ubuntu
-  check:
-    image: $(params.image)
-```
-
-Parameter names:
-- Must only contain alphanumeric characters, hyphens (`-`), and underscores (`_`).
-- Must begin with a letter or an underscore (`_`).
-
-For example, `fooIs-Bar_` is a valid parameter name, but `barIsBa$` or `0banana` are not.
-
-Each declared parameter has a `type` field, which can be set to either `array` or `string`, and
-defaults to `string` if you don't specify a value. The `description` and `default` fields for a
-`Parameter` are optional. The `array` type is useful in situations such as checking that a pushed
-branch name doesn't collide with any of the specified protected branch names.
-
-### Specifying `Resources`
-
-> :warning: **`PipelineResources` are [deprecated](deprecations.md#deprecation-table).**
->
-> Consider using replacement features instead. Read more in [documentation](migrating-v1alpha1-to-v1beta1.md#replacing-pipelineresources-with-tasks)
-> and [TEP-0074](https://github.com/tektoncd/community/blob/main/teps/0074-deprecate-pipelineresources.md).
-
-You can specify input [`PipelineResources`](resources.md) in your `Condition` definition to 
-provide the `Condition's` container step with data or context necessary to run the evaluation logic.
-
-`Resources` in `Conditions` behave the same way as in `Tasks`:
-- You can access them via [variable substitution](resources.md#variable-substitution).
-- You can use the `targetPath` field to [specify a mount point](resources.md#controlling-where-resources-are-mounted).
-
-### Adding a `description`
-
-The `description` field (optional) allows you to specify a meaningful description for your `Condition`.
-
-## Code examples
-
-For a better understanding of `Conditions`, study [our code examples](https://github.com/tektoncd/pipeline/tree/main/examples).
+**Note:** `Conditions` have been removed as of Pipeline 0.37.0, use [`when` expressions](pipelines.md#guard-task-execution-using-when-expressions) instead. 
 
 ---
 

docs/labels.md

@@ -36,8 +36,6 @@ and then to the associated `Pods`. As for `Pipeline` and `PipelineRun`, if a lab
 propagate from the [referenced `Task`](taskruns.md#specifying-the-target-task), if one exists, to
 the corresponding `TaskRun`, and then to the associated `Pod`. The same as above applies.
 
-- For `Conditions`, labels propagate to the corresponding `TaskRuns`, and then to the associated `Pods`.
-
 ## Automatic labeling
 
 Tekton automatically adds labels to Tekton entities as described in the following table.
@@ -135,5 +133,3 @@ and then to the associated `Pods`. As for `Pipeline` and `PipelineRun`, if a ann
 - For standalone `TaskRuns` (that is, ones not executing as part of a `Pipeline`), annotations
 propagate from the [referenced `Task`](taskruns.md#specifying-the-target-task), if one exists, to
 the corresponding `TaskRun`, and then to the associated `Pod`. The same as above applies.
-
-- For `Conditions`, annotations propagate to the corresponding `TaskRuns`, and then to the associated `Pods`.

docs/pipelineruns.md

@@ -893,7 +893,6 @@ Your `PipelineRun`'s `status` field can contain the following fields:
   - `childReferences` - A list of references to each `TaskRun` or `Run` in this `PipelineRun`, which can be used to look up the status of the underlying `TaskRun` or `Run`. Each entry contains the following:
     - [`kind`][kubernetes-overview] - Generally either `TaskRun` or `Run`.
     - [`apiVersion`][kubernetes-overview] - The API version for the underlying `TaskRun` or `Run`.
-    - `conditionChecks` - A list of [condition checks](conditions.md) performed for this `TaskRun`. `conditions` are deprecated and this will be removed in the future.
     - [`whenExpressions`](pipelines.md#guard-task-execution-using-when-expressions) - The list of when expressions guarding the execution of this task.
 
 ### Configuring usage of `TaskRun` and `Run` embedded statuses
@@ -915,7 +914,7 @@ information on feature flags. The possible values for `embedded-status` are:
 As your `PipelineRun` executes, its `status` field accumulates information on the execution of each `TaskRun`
 as well as the `PipelineRun` as a whole. This information includes the name of the pipeline `Task` associated
 to a `TaskRun`, the complete [status of the `TaskRun`](taskruns.md#monitoring-execution-status) and details
-about `Conditions` that may be associated to a `TaskRun`.
+about `whenExpressions` that may be associated to a `TaskRun`.
 
 The following example shows an extract from the `status` field of a `PipelineRun` that has executed successfully: