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
TEP-0075(object params and results) promoted to stable
Pipeline 0.46 introduced object params and results. This commit is
promoting TEP-0075 to stable such that these features can be used by
the task authors and pipeline authors in a cluster when enable-api-fields is alpha,beta or stable.
Signed-off-by: Yongxuan Zhang yongxuanzhang@google.com
-[Mapping <code>ServiceAccount</code> credentials to <code>Tasks</code>](#mapping-serviceaccount-credentials-to-tasks)
25
25
-[Specifying a <code>Pod</code> template](#specifying-a-pod-template)
@@ -71,12 +71,12 @@ A `PipelineRun` definition supports the following fields:
71
71
-[`params`](#specifying-parameters) - Specifies the desired execution parameters for the `Pipeline`.
72
72
-[`serviceAccountName`](#specifying-custom-serviceaccount-credentials) - Specifies a `ServiceAccount`
73
73
object that supplies specific execution credentials for the `Pipeline`.
74
-
-[`status`](#cancelling-a-pipelinerun) - Specifies options for cancelling a `PipelineRun`.
74
+
-[`status`](#cancelling-a-pipelinerun) - Specifies options for cancelling a `PipelineRun`.
75
75
-[`taskRunSpecs`](#specifying-taskrunspecs) - Specifies a list of `PipelineRunTaskSpec` which allows for setting `ServiceAccountName`, [`Pod` template](./podtemplates.md), and `Metadata` for each task. This overrides the `Pod` template set for the entire `Pipeline`.
76
76
-[`timeout`](#configuring-a-failure-timeout) - Specifies the timeout before the `PipelineRun` fails. `timeout` is deprecated and will eventually be removed, so consider using `timeouts` instead.
77
77
-[`timeouts`](#configuring-a-failure-timeout) - Specifies the timeout before the `PipelineRun` fails. `timeouts` allows more granular timeout configuration, at the pipeline, tasks, and finally levels
78
78
-[`podTemplate`](#specifying-a-pod-template) - Specifies a [`Pod` template](./podtemplates.md) to use as the basis for the configuration of the `Pod` that executes each `Task`.
79
-
-[`workspaces`](#specifying-workspaces) - Specifies a set of workspace bindings which must match the names of workspaces declared in the pipeline being used.
79
+
-[`workspaces`](#specifying-workspaces) - Specifies a set of workspace bindings which must match the names of workspaces declared in the pipeline being used.
@@ -275,9 +275,9 @@ go through the complexity of checking each `Pipeline` and providing only the req
275
275
276
276
> :seedling: **`enum` is an [alpha](additional-configs.md#alpha-features) feature.** The `enable-param-enum` feature flag must be set to `"true"` to enable this feature.
277
277
278
-
If a `Parameter` is guarded by `Enum` in the `Pipeline`, you can only provide `Parameter` values in the `PipelineRun` that are predefined in the `Param.Enum` in the `Pipeline`. The `PipelineRun` will fail with reason `InvalidParamValue` otherwise.
278
+
If a `Parameter` is guarded by `Enum` in the `Pipeline`, you can only provide `Parameter` values in the `PipelineRun` that are predefined in the `Param.Enum` in the `Pipeline`. The `PipelineRun` will fail with reason `InvalidParamValue` otherwise.
279
279
280
-
Tekton will also the validate the `param` values passed to any referenced `Tasks` (via `taskRef`) if `Enum` is specified for the `Task`. The `PipelineRun` will fail with reason `InvalidParamValue` if `Enum` validation is failed for any of the `PipelineTask`.
280
+
Tekton will also the validate the `param` values passed to any referenced `Tasks` (via `taskRef`) if `Enum` is specified for the `Task`. The `PipelineRun` will fail with reason `InvalidParamValue` if `Enum` validation is failed for any of the `PipelineTask`.
281
281
282
282
You can also specify `Enum` in an embedded `Pipeline` in a `PipelineRun`. The same `Param` validation will be executed in this scenario.
283
283
@@ -579,43 +579,41 @@ status:
579
579
580
580
##### Object Parameters
581
581
582
-
Object params is a [beta feature](./additional-configs.md#beta-features).
583
-
584
582
When using an inlined spec, object parameters from the parent `PipelineRun` will also be
585
583
propagated to any inlined specs without needing to be explicitly defined. This
586
584
allows authors to simplify specs by automatically propagating top-level
587
585
parameters down to other inlined resources.
588
586
When propagating object parameters, scope and precedence also holds as shown below.
echo hi >> $(workspaces.shared-data.path)/recipe.txt
1122
1120
- name: print-the-recipe
1123
1121
# workspaces:
1124
-
# - name: shared-data
1122
+
# - name: shared-data
1125
1123
runAfter:
1126
1124
- fetch-secure-data
1127
1125
taskSpec:
1128
1126
# workspaces:
1129
-
# - name: shared-data
1127
+
# - name: shared-data
1130
1128
steps:
1131
1129
- name: print-secrets
1132
1130
image: ubuntu
@@ -1259,7 +1257,7 @@ spec:
1259
1257
- name: fetch-and-write
1260
1258
image: ubuntu
1261
1259
script: |
1262
-
echo $(workspaces.shared-data.path)
1260
+
echo $(workspaces.shared-data.path)
1263
1261
---
1264
1262
apiVersion: tekton.dev/v1 # or tekton.dev/v1beta1
1265
1263
kind: PipelineRun
@@ -1432,7 +1430,7 @@ If you set the timeout to 0, the `PipelineRun` fails immediately upon encounteri
1432
1430
Your `PipelineRun`'s `status` field can contain the following fields:
1433
1431
1434
1432
- Required:
1435
-
- `status`- Most relevant, `status.conditions`, which contains the latest observations of the `PipelineRun`'s state. [See here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) for information on typical status properties.
1433
+
- `status`- Most relevant, `status.conditions`, which contains the latest observations of the `PipelineRun`'s state. [See here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) for information on typical status properties.
1436
1434
- `startTime`- The time at which the `PipelineRun` began executing, in [RFC3339](https://tools.ietf.org/html/rfc3339) format.
1437
1435
- `completionTime`- The time at which the `PipelineRun` finished executing, in [RFC3339](https://tools.ietf.org/html/rfc3339) format.
1438
1436
- [`pipelineSpec`](pipelines.md#configuring-a-pipeline) - The exact `PipelineSpec` used when starting the `PipelineRun`.
Copy file name to clipboardExpand all lines: docs/pipelines.md
+4-4Lines changed: 4 additions & 4 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -301,8 +301,8 @@ spec:
301
301
If the `Param` value passed in by `PipelineRun` is **NOT** in the predefined `enum` list, the `PipelineRun` will fail with reason `InvalidParamValue`.
302
302
303
303
If a `PipelineTask` references a `Task` with `enum`, the `enums` specified in the Pipeline `spec.params` (pipeline-level `enum`) must be
304
-
a **subset** of the `enums` specified in the referenced `Task` (task-level `enum`). An empty pipeline-level `enum` is invalid
305
-
in this scenario since an empty `enum` set indicates a "universal set" which allows all possible values. The same rules apply to `Pipelines` with embbeded `Tasks`.
304
+
a **subset** of the `enums` specified in the referenced `Task` (task-level `enum`). An empty pipeline-level `enum` is invalid
305
+
in this scenario since an empty `enum` set indicates a "universal set" which allows all possible values. The same rules apply to `Pipelines` with embbeded `Tasks`.
306
306
307
307
In the below example, the referenced `Task` accepts `v1` and `v2` as valid values, the `Pipeline` further restricts the valid value to `v1`.
308
308
@@ -1280,7 +1280,7 @@ Sharing `Results` between `Tasks` in a `Pipeline` happens via
1280
1280
a `Result` and another receives it as a `Parameter` with a variable such as
1281
1281
`$(tasks.<task-name>.results.<result-name>)`. Pipeline support two new types of
1282
1282
results and parameters: array `[]string` and object `map[string]string`.
1283
-
Array and Object result is a beta feature and can be enabled by setting `enable-api-fields` to `alpha` or `beta`.
1283
+
Array result is a beta feature and can be enabled by setting `enable-api-fields` to `alpha` or `beta`.
1284
1284
1285
1285
| Result Type | Parameter Type | Specification | `enable-api-fields` |
Copy file name to clipboardExpand all lines: docs/taskruns.md
+33-35Lines changed: 33 additions & 35 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -304,10 +304,10 @@ status:
304
304
reason: Succeeded
305
305
status: "True"
306
306
type: Succeeded
307
-
...
307
+
...
308
308
steps:
309
309
- container: step-default
310
-
...
310
+
...
311
311
taskSpec:
312
312
steps:
313
313
- image: ubuntu
@@ -317,8 +317,6 @@ status:
317
317
```
318
318
319
319
#### Propagated Object Parameters
320
-
Object params is a [beta feature](./additional-configs.md#beta-features).
321
-
322
320
When using an inlined `taskSpec`, object parameters from the parent `TaskRun` will be
323
321
available to the `Task` without needing to be explicitly defined.
324
322
@@ -438,13 +436,13 @@ spec:
438
436
apiVersion: tekton.dev/v1 # or tekton.dev/v1beta1
439
437
kind: TaskRun
440
438
metadata:
441
-
name: taskrun
439
+
name: taskrun
442
440
spec:
443
441
taskRef:
444
442
name: task
445
443
computeResources:
446
444
requests:
447
-
cpu: 1
445
+
cpu: 1
448
446
limits:
449
447
cpu: 2
450
448
```
@@ -524,21 +522,21 @@ workspaces down to other inlined resources.
524
522
**Workspace substutions will only be made for `commands`, `args` and `script` fields of `steps`, `stepTemplates`, and `sidecars`.**
525
523
526
524
```yaml
527
-
apiVersion: tekton.dev/v1 # or tekton.dev/v1beta1
528
-
kind: TaskRun
525
+
apiVersion: tekton.dev/v1 # or tekton.dev/v1beta1
526
+
kind: TaskRun
529
527
metadata:
530
528
generateName: propagating-workspaces-
531
529
spec:
532
-
taskSpec:
533
-
steps:
534
-
- name: simple-step
535
-
image: ubuntu
536
-
command:
537
-
- echo
538
-
args:
530
+
taskSpec:
531
+
steps:
532
+
- name: simple-step
533
+
image: ubuntu
534
+
command:
535
+
- echo
536
+
args:
539
537
- $(workspaces.tr-workspace.path)
540
-
workspaces:
541
-
- emptyDir: {}
538
+
workspaces:
539
+
- emptyDir: {}
542
540
name: tr-workspace
543
541
```
544
542
@@ -564,32 +562,32 @@ status:
564
562
565
563
##### Propagating Workspaces to Referenced Tasks
566
564
567
-
Workspaces can only be propagated to `embedded` task specs, not `referenced` Tasks.
565
+
Workspaces can only be propagated to `embedded` task specs, not `referenced` Tasks.
568
566
569
567
```yaml
570
-
apiVersion: tekton.dev/v1 # or tekton.dev/v1beta1
571
-
kind: Task
568
+
apiVersion: tekton.dev/v1 # or tekton.dev/v1beta1
569
+
kind: Task
572
570
metadata:
573
571
name: workspace-propagation
574
572
spec:
575
573
steps:
576
-
- name: simple-step
577
-
image: ubuntu
578
-
command:
579
-
- echo
580
-
args:
574
+
- name: simple-step
575
+
image: ubuntu
576
+
command:
577
+
- echo
578
+
args:
581
579
- $(workspaces.tr-workspace.path)
582
580
---
583
-
apiVersion: tekton.dev/v1 # or tekton.dev/v1beta1
581
+
apiVersion: tekton.dev/v1 # or tekton.dev/v1beta1
584
582
kind: TaskRun
585
583
metadata:
586
584
generateName: propagating-workspaces-
587
585
spec:
588
-
taskRef:
586
+
taskRef:
589
587
name: workspace-propagation
590
-
workspaces:
591
-
- emptyDir: {}
592
-
name: tr-workspace
588
+
workspaces:
589
+
- emptyDir: {}
590
+
name: tr-workspace
593
591
```
594
592
595
593
Upon execution, the above `TaskRun` will fail because the `Task` is referenced and workspace is not propagated. It must be explicitly defined in the `spec` of the defined `Task`.
@@ -788,7 +786,7 @@ The `status` field defines the observed state of `TaskRun`
788
786
### The `status` field
789
787
- Required:
790
788
- `status` - The most relevant information about the TaskRun's state. This field includes:
791
-
- `status.conditions`, which contains the latest observations of the `TaskRun`'s state. [See here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) for information on typical status properties.
789
+
- `status.conditions`, which contains the latest observations of the `TaskRun`'s state. [See here](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#typical-status-properties) for information on typical status properties.
792
790
- `podName`- Name of the pod containing the containers responsible for executing this `task`'s `step`s.
793
791
- `startTime`- The time at which the `TaskRun` began executing, conforms to [RFC3339](https://tools.ietf.org/html/rfc3339) format.
794
792
- `completionTime`- The time at which the `TaskRun` finished executing, conforms to [RFC3339](https://tools.ietf.org/html/rfc3339) format.
@@ -802,11 +800,11 @@ The `status` field defines the observed state of `TaskRun`
802
800
- `featureFlags`: Identifies the feature flags used during the `TaskRun`.
803
801
- `steps`- Contains the `state` of each `step` container.
804
802
- `retriesStatus`- Contains the history of `TaskRun`'s `status` in case of a retry in order to keep record of failures. No `status` stored within `retriesStatus` will have any `date` within as it is redundant.
805
-
803
+
806
804
- [`sidecars`](tasks.md#using-a-sidecar-in-a-task) - This field is a list. The list has one entry per `sidecar` in the manifest. Each entry represents the imageid of the corresponding sidecar.
0 commit comments