You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: teps/0007-conditions-beta.md
+6-82
Original file line number
Diff line number
Diff line change
@@ -3,8 +3,8 @@ title: Conditions Beta
3
3
authors:
4
4
- "@jerop"
5
5
creation-date: 2020-07-22
6
-
last-updated: 2020-11-02
7
-
status: implementable
6
+
last-updated: 2020-06-03
7
+
status: implemented
8
8
---
9
9
10
10
# TEP-0007: Conditions Beta
@@ -30,7 +30,6 @@ tags, and then generate with `hack/update-toc.sh`.
30
30
-[Proposal](#proposal)
31
31
-[Simplicity](#simplicity-1)
32
32
-[Efficiency](#efficiency-1)
33
-
-[Skipping](#skipping-1)
34
33
-[Status](#status-1)
35
34
-[Examples](#examples)
36
35
-[Risks and Mitigations](#risks-and-mitigations)
@@ -41,10 +40,6 @@ tags, and then generate with `hack/update-toc.sh`.
41
40
-[Efficiency](#efficiency-2)
42
41
-[CelRun Custom Task](#celrun-custom-task)
43
42
-[Expression Language Interceptor](#expression-language-interceptor)
44
-
-[Skipping](#skipping-2)
45
-
-[Dependency Type](#dependency-type)
46
-
-[Guard Location](#guard-location)
47
-
-[Special runAfter](#special-runafter)
48
43
-[Status](#status-2)
49
44
-[Minimal Skipped](#minimal-skipped)
50
45
-[ConditionSucceeded](#conditionsucceeded)
@@ -65,9 +60,10 @@ We will refer to `Conditions` as `Guards` because they determine **if** a `Task`
65
60
We propose:
66
61
- For _simplicity_, we propose **deprecating the separate `Conditions` CRD** and using `Tasks` to produce the `Results` needed to evaluate whether a dependent `Task` executes.
67
62
- For _efficiency_, we propose using string expressions through `When Expressions` to perform simple checks without spinning up new `Pods`; they can operate on previous `Task's Results`, `Parameters`, among other Tekton resources.
68
-
- For _skipping_, we propose adding a field that allows users to specify whether to skip the guarded `Task` only or to skip the guarded `Task` and its ordering-dependent `Tasks`.
69
63
- By deprecating `Conditions` CRD and using `When Expressions`, we can distinguish failed _status_ from evaluating to `False`.
70
64
65
+
We address _skipping_ separately in [TEP-0059: Skipping Strategies](https://github.com/tektoncd/community/blob/main/teps/0059-skipping-strategies.md).
66
+
71
67
## Background
72
68
73
69
### Conditions
@@ -175,9 +171,10 @@ It is currently difficult to distinguish between a `Task` that was skipped due t
175
171
We propose:
176
172
- For _simplicity_, we propose deprecating the separate `Conditions` CRD and using `Tasks` to produce the `Results` needed to evaluate whether a dependent `Task` executes.
177
173
- For _efficiency_, we propose using string expressions through `When Expressions` to perform simple checks without spinning up new `Pods`; they can operate on previous `Task's Results`, `Parameters`, among other Tekton resources.
178
-
- For _skipping_, we propose adding a field that allows users to specify whether to skip the guarded `Task` only or to skip the guarded `Task` and its ordering-dependent `Tasks`.
179
174
- By deprecating `Conditions` CRD and using `When Expressions`, we can distinguish failed _status_ from evaluating to `False`.
180
175
176
+
We address _skipping_ separately in [TEP-0059: Skipping Strategies](https://github.com/tektoncd/community/blob/main/teps/0059-skipping-strategies.md).
177
+
181
178
### Simplicity
182
179
183
180
As discussed in the background section, `Conditions` manifest themselves as `Tasks`. We want to keep Tekton as simple as possible by reusing existing components. So we propose phasing out the separate `Conditions` CRD and eventually deprecating it. In place of `Conditions`, we propose using `Tasks` produce to `Results` that we can use to specify `Guards` using `When Expressions` in subsequent `Tasks`, as described in [Efficiency](#efficiency) section below. Thus, we won’t have `Conditions` to migrate to beta and won’t have to maintain the separate `Conditions` CRD.
@@ -293,60 +290,6 @@ values: [‘’]
293
290
294
291
We can explore adding more [Operators](https://github.com/kubernetes/kubernetes/blob/7f23a743e8c23ac6489340bbb34fa6f1d392db9d/staging/src/k8s.io/apimachinery/pkg/selection/operator.go) later if needed, such as `IsTrue`, `IsFalse`, `IsEmpty` and `IsNotEmpty`. Kubernetes' `Match Expressions` uses a comma separator as an `AND` operator but it won't be supported in Tekton's `When Expressions` (can be revisted later).
295
292
296
-
### Skipping
297
-
298
-
As it is currently in `Conditions`, when `WhenExpressions` evaluate to `False`, the `Task` and its branch (of dependent `Tasks`) will be skipped by default while the rest of the `Pipeline` will execute.
299
-
300
-
A `Task` branch is made up of dependent `Tasks`, where there are two types of dependencies:
301
-
- _Resource dependency_: based on resources needed from parent `Task`, which includes `Results` and `Resources`.
302
-
- _Ordering dependency_: based on `runAfter` which provides sequencing of `Tasks` when there may not be resource dependencies.
303
-
304
-
To provide more flexibility when `WhenExpressions` evaluate to `False`, we propose adding a field - `whenSkipped` - that:
305
-
- is used to specify whether to execute `Tasks` that are ordering-dependent on the skipped guarded `Task`
306
-
- defaults to `skipBranch` and users can set it to `runBranch` to allow execution of the rest of the branch
307
-
- can be specified in `Tasks` guarded with `WhenExpressions` only; there will be a validation error if `whenSkipped` is specified in `Tasks` without `WhenExpressions`
308
-
- can take the values `skipBranch` or `runBranch` only; there will be a validation error if anything else is passed to `whenSkipped`
309
-
- can be specified guarded `Tasks` with ordering dependencies only; there will be a validation error if `whenSkipped` is specified in `Tasks` with resource dependencies
310
-
311
-
Here's how a user can use `whenSkipped` to execute ordering-dependent tasks:
312
-
313
-
```yaml
314
-
api: tekton.dev/v1beta1
315
-
kind: Pipeline
316
-
metadata:
317
-
name: generate-file
318
-
spec:
319
-
workspaces:
320
-
- name: source-repo
321
-
params:
322
-
- name: path
323
-
default: 'README.md'
324
-
tasks:
325
-
- name: create-file # executed
326
-
taskRef:
327
-
name: create-readme-file
328
-
workspaces:
329
-
- name: source
330
-
workspace: source-repo
331
-
- name: file-exists # executed
332
-
taskRef:
333
-
name: file-exists
334
-
workspaces:
335
-
- name: source
336
-
workspace: source-repo
337
-
- name: echo-file-does-not-exist # skipped
338
-
when:
339
-
- input: '$(tasks.file-exists.results.exists)'
340
-
operator: In
341
-
values: ['false']
342
-
whenSkipped: runBranch
343
-
taskRef:
344
-
name: echo-file-exists
345
-
- name: echo-hello # executed
346
-
taskRef: echo-hello
347
-
runAfter:
348
-
- echo-file-does-not-exist
349
-
```
350
293
351
294
### Status
352
295
@@ -713,25 +656,6 @@ spec:
713
656
714
657
To make it flexible, similarly to Triggers which uses language interceptors that's pluggable, we can provide a `CEL` interceptor out of the box and, if needed, users can add or bring their own interceptors to use other languages.
715
658
716
-
### Skipping
717
-
718
-
#### Dependency Type
719
-
As described in [Skipping](#skipping) section above, a `Task` can have _resource dependency_ or _ordering dependency_ on a parent `Task`. Executing resource-dependent `Tasks` is invalid since because they'll have resource resolution errors. Thus, we could execute the ordering-dependent `Tasks` and terminate the resource-dependent `Tasks`.
720
-
721
-
However, this default behavior would remove the option to skip ordering-dependent `Tasks` if users want that, and the modified behavior may not be transparent to users.
722
-
723
-
#### Guard Location
724
-
`Guards` can be defined in two locations:
725
-
- Within a `Task`: if expression evaluates to `False`, only that `Task` is skipped.
726
-
- Between `Tasks`: if the expression evaluates to `False`, the subsequent `Tasks` are skipped.
727
-
728
-
However, the implicit behavior may be confusing to users.
729
-
730
-
#### Special runAfter
731
-
Provide a special kind of `runAfter` -- `runAfterEvenWhenSkipped` -- that users can use instead of `runAfter` to allow for the ordering-dependent `Task` to execute even when the `Task` has been skipped. Related ideas are discussed in [#2653](https://github.com/tektoncd/pipeline/issues/2635) as `runAfterUnconditionally` and [#1684](https://github.com/tektoncd/pipeline/issues/1684) as `runOn`.
732
-
733
-
However, this would make what happens to the branch opaque to the guarded `Task` because its ordering-dependent `Tasks` could be executed or not be executed.
|[TEP-0008](0008-support-knative-service-for-triggers-eventlistener-pod.md)| Support Knative Service for Triggers EventListener Pod | implementable | 2020-08-25 |
0 commit comments