Deprecate Conditions CRD

[jerop]

With the implementation of Conditions Beta, specifically WhenExpressions, we want to deprecate the Conditions CRD because:

• Efficiency: Conditions have to spin up new Pods for every check, even simple ones. WhenExpressions enable guarding Tasks with simple checks without spinning up new Pods. Read more.
• Simplicity: Conditions actually manifested themselves as Tasks. In more complex use cases, we can use Tasks themselves to produce Results that can be used to specify WhenExpressions in subsequent Tasks. Read more.
• Flexibility: When Conditions evaluated to False and the associated Task was skipped, the subsequent Tasks were skipped as well. Tasks guarded by WhenExpressions support passing in a field -continueAfterSkip - that enables ordering-dependent Tasks to execute when it is set to True. Read more.
• Status: It is difficult to distinguish Conditions causing a Task to be skipped or the Task failing for other reasons. When WhenExpressions evaluate to false, the associated Task is listed in a Skipped Tasks section of the status alongside the resolved WhenExpressions. If they evaluate to True, the resolved WhenExpressions are listed alongside the TaskRun status. Read more.

Conditions CRD has been listed in the deprecations table since the release of v0.16.0.

This is a milestone for release of Pipelines v1beta2.

cc @bobcatfish

[jerop]

/kind cleanup

[tekton-robot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[vdemeester]

/remove-lifecycle stale
/lifecycle frozen
/area roadmap

[afrittoli]

@jerop @vdemeester @bobcatfish Do we need a v1beta2 to remove Conditions?
They have been deprecated since v0.16.0 and we Nov 2020 was the first time we could have removed them according to the policy.

[jerop]

I don't think it's worth the effort to create v1beta2 just to remove Conditions, especially given that we're already working towards v1 which won't have Conditions - TEP-0096

[afrittoli]

We could stop simply stop serving Conditions in v1alpha1 - the problem is however that Conditions can be included in v1beta1/Pipeline. Once we release the v1 version of Pipeline, even if we deprecate v1beta1 right away, we will need to serve v1beta1 for 9 months, which includes support for references of Conditions.

I think there are three possible ways forward:

1. we stop serving Conditions even if we still serve CRDs that may refer to them
2. we deprecate v1beta1 as soon as possible, and make a v1beta2 which does not allow for references to Conditions. In nine months from now, we can drop v1beta1 and remove Conditions
3. we deprecate v1beta when we release v1 and nine months later we can drop v1beta1 and remove Conditions

Option (1) feels a bit ugly, and option (2) feels like a lot of work for a v1beta2 which no-one will ever use. Option (3) seems like a long time we'll need to keep Conditions around, but perhaps it's still the best way forward.

As a side note, all of the above applies to PipelineResources too.

@tektoncd/core-maintainers @lbernick

[vdemeester]

I think we don't really have any other decent choice than (2) or (3), and I would lean more on (3)

[lbernick]

I agree with Vincent that option 3 is best. Option 2 would follow the letter of our compatibility policy but as you said, not provide much benefit to users in exchange for a large amount of work on our part.

[lbernick]

Discussed in API WG this week and on slack: we plan to remove Conditions from v1beta1 CRDs in v0.37.0.

[abayer]

/assign