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
This is part of work in TEP-0076.
This commit provides the support to apply array results replacements.
Previous this commit we support emitting array results so users can
write array results to task level, but we cannot pass array results from
tasks within one pipeline. This commit adds the support for this.
Copy file name to clipboardExpand all lines: docs/pipelines.md
+28-23Lines changed: 28 additions & 23 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -95,7 +95,7 @@ A `Pipeline` definition supports the following fields:
95
95
a `Task` requires.
96
96
-[`from`](#using-the-from-field) - Indicates the data for a [`PipelineResource`](resources.md)
97
97
originates from the output of a previous `Task`.
98
-
-[`runAfter`](#using-the-runafter-field) - Indicates that a `Task` should execute after one or more other
98
+
-[`runAfter`](#using-the-runafter-field) - Indicates that a `Task` should execute after one or more other
99
99
`Tasks` without output linking.
100
100
-[`retries`](#using-the-retries-field) - Specifies the number of times to retry the execution of a `Task` after
101
101
a failure. Does not apply to execution cancellations.
@@ -109,7 +109,7 @@ A `Pipeline` definition supports the following fields:
109
109
-[`results`](#emitting-results-from-a-pipeline) - Specifies the location to which the `Pipeline` emits its execution
110
110
results.
111
111
-[`description`](#adding-a-description) - Holds an informative description of the `Pipeline` object.
112
-
-[`finally`](#adding-finally-to-the-pipeline) - Specifies one or more `Tasks` to be executed in parallel after
112
+
-[`finally`](#adding-finally-to-the-pipeline) - Specifies one or more `Tasks` to be executed in parallel after
113
113
all other tasks have completed.
114
114
-[`name`](#adding-finally-to-the-pipeline) - the name of this `Task` within the context of this `Pipeline`.
115
115
-[`taskRef`](#adding-finally-to-the-pipeline) - a reference to a `Task` definition.
@@ -174,7 +174,7 @@ spec:
174
174
workspace: pipeline-ws1
175
175
```
176
176
177
-
For simplicity you can also map the name of the `Workspace` in `PipelineTask` to match with
177
+
For simplicity you can also map the name of the `Workspace` in `PipelineTask` to match with
178
178
the `Workspace` from the `Pipeline`.
179
179
For example:
180
180
@@ -191,12 +191,12 @@ spec:
191
191
taskRef:
192
192
name: gen-code # gen-code expects a Workspace named "source"
193
193
workspaces:
194
-
- name: source # <- mapping workspace name
194
+
- name: source # <- mapping workspace name
195
195
- name: commit
196
196
taskRef:
197
197
name: commit # commit expects a Workspace named "source"
198
198
workspaces:
199
-
- name: source # <- mapping workspace name
199
+
- name: source # <- mapping workspace name
200
200
runAfter:
201
201
- gen-code
202
202
```
@@ -402,7 +402,7 @@ spec:
402
402
`"true"`in the `feature-flags` configmap, see [`install.md`](./install.md#customizing-the-pipelines-controller-behavior)**
403
403
404
404
You may also specify your `Task` reference using a `Tekton Bundle`. A `Tekton Bundle` is an OCI artifact that
405
-
contains Tekton resources like `Tasks` which can be referenced within a `taskRef`.
405
+
contains Tekton resources like `Tasks` which can be referenced within a `taskRef`.
406
406
407
407
There is currently a hard limit of 20 objects in a bundle.
408
408
@@ -628,7 +628,7 @@ To guard a `Task` and its dependent Tasks:
628
628
629
629
##### Cascade `when` expressions to the specific dependent `Tasks`
630
630
631
-
Pick and choose which specific dependent `Tasks` to guard as well, and cascade the `when` expressions to those `Tasks`.
631
+
Pick and choose which specific dependent `Tasks` to guard as well, and cascade the `when` expressions to those `Tasks`.
632
632
633
633
Taking the use case below, a user who wants to guard `manual-approval` and its dependent `Tasks`:
634
634
@@ -689,12 +689,12 @@ tasks:
689
689
value: $(tasks.manual-approval.results.approver)
690
690
taskRef:
691
691
name: slack-msg
692
-
```
692
+
```
693
693
694
694
##### Compose using Pipelines in Pipelines
695
695
696
-
Compose a set of `Tasks` as a unit of execution using `Pipelines` in `Pipelines`, which allows for guarding a `Task` and
697
-
its dependent `Tasks` (as a sub-`Pipeline`) using `when` expressions.
696
+
Compose a set of `Tasks` as a unit of execution using `Pipelines` in `Pipelines`, which allows for guarding a `Task` and
697
+
its dependent `Tasks` (as a sub-`Pipeline`) using `when` expressions.
698
698
699
699
**Note:** `Pipelines` in `Pipelines` is an [experimental feature](https://github.com/tektoncd/experimental/tree/main/pipelines-in-pipelines)
700
700
@@ -742,7 +742,7 @@ tasks:
742
742
value: $(tasks.manual-approval.results.approver)
743
743
taskRef:
744
744
name: slack-msg
745
-
745
+
746
746
---
747
747
## main pipeline
748
748
tasks:
@@ -765,12 +765,12 @@ tasks:
765
765
766
766
When `when` expressions evaluate to `False`, the `Task` will be skipped and:
767
767
- The ordering-dependent `Tasks` will be executed
768
-
- The resource-dependent `Tasks` (and their dependencies) will be skipped because of missing `Results` from the skipped
769
-
parent `Task`. When we add support for [default `Results`](https://github.com/tektoncd/community/pull/240), then the
770
-
resource-dependent `Tasks` may be executed if the default `Results` from the skipped parent `Task` are specified. In
768
+
- The resource-dependent `Tasks` (and their dependencies) will be skipped because of missing `Results` from the skipped
769
+
parent `Task`. When we add support for [default `Results`](https://github.com/tektoncd/community/pull/240), then the
770
+
resource-dependent `Tasks` may be executed if the default `Results` from the skipped parent `Task` are specified. In
771
771
addition, if a resource-dependent `Task` needs a file from a guarded parent `Task` in a shared `Workspace`, make sure
772
-
to handle the execution of the child `Task` in case the expected file is missing from the `Workspace` because the
773
-
guarded parent `Task` is skipped.
772
+
to handle the execution of the child `Task` in case the expected file is missing from the `Workspace` because the
773
+
guarded parent `Task` is skipped.
774
774
775
775
On the other hand, the rest of the `Pipeline` will continue executing.
776
776
@@ -823,12 +823,12 @@ tasks:
823
823
name: slack-msg
824
824
```
825
825
826
-
If `manual-approval` is skipped, execution of its dependent `Tasks` (`slack-msg`, `build-image` and `deploy-image`)
826
+
If `manual-approval` is skipped, execution of its dependent `Tasks` (`slack-msg`, `build-image` and `deploy-image`)
827
827
would be unblocked regardless:
828
828
-`build-image` and `deploy-image` should be executed successfully
829
829
-`slack-msg` will be skipped because it is missing the `approver``Result` from `manual-approval`
830
830
- dependents of `slack-msg` would have been skipped too if it had any of them
831
-
- if `manual-approval` specifies a default `approver``Result`, such as "None", then `slack-msg` would be executed
831
+
- if `manual-approval` specifies a default `approver``Result`, such as "None", then `slack-msg` would be executed
832
832
([supporting default `Results` is in progress](https://github.com/tektoncd/community/pull/240))
833
833
834
834
### Configuring the failure timeout
@@ -908,7 +908,10 @@ Tasks can emit [`Results`](tasks.md#emitting-results) when they execute. A Pipel
908
908
Sharing `Results` between `Tasks` in a `Pipeline` happens via
909
909
[variable substitution](variables.md#variables-available-in-a-pipeline) - one `Task` emits
910
910
a `Result` and another receives it as a `Parameter` with a variable such as
911
-
`$(tasks.<task-name>.results.<result-name>)`.
911
+
`$(tasks.<task-name>.results.<result-name>)`. Array `Results` is supported as alpha feature and
912
+
can be referer as `$(tasks.<task-name>.results.<result-name>[*])`.
913
+
914
+
**Note:** Array `Result` cannot be used in `script`.
912
915
913
916
When one `Task` receives the `Results` of another, there is a dependency created between those
914
917
two `Tasks`. In order for the receiving `Task` to get data from another `Task's` `Result`,
Copy file name to clipboardExpand all lines: docs/variables.md
+3Lines changed: 3 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -25,6 +25,9 @@ For instructions on using variable substitutions see the relevant section of [th
25
25
|`tasks.<taskName>.results.<resultName>[i]`| The ith value of the `Task's` array result. Can alter `Task` execution order within a `Pipeline`.) |
26
26
|`tasks.<taskName>.results['<resultName>'][i]`| (see above)) |
27
27
|`tasks.<taskName>.results["<resultName>"][i]`| (see above)) |
28
+
|`tasks.<taskName>.results.<resultName>[*]`| The array value of the `Task's` result. Can alter `Task` execution order within a `Pipeline`. Cannot be used in `script`.) |
29
+
|`tasks.<taskName>.results['<resultName>'][*]`| (see above)) |
30
+
|`tasks.<taskName>.results["<resultName>"][*]`| (see above)) |
28
31
|`workspaces.<workspaceName>.bound`| Whether a `Workspace` has been bound or not. "false" if the `Workspace` declaration has `optional: true` and the Workspace binding was omitted by the PipelineRun. |
29
32
|`context.pipelineRun.name`| The name of the `PipelineRun` that this `Pipeline` is running in. |
30
33
|`context.pipelineRun.namespace`| The namespace of the `PipelineRun` that this `Pipeline` is running in. |
0 commit comments