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
triger template description changes and release branch changes
rpm updates
clarification on trigger template and pipeline run creation
attributes and typo
replacing with version attribute
attribute label
build fix
attribute changes
attribute and build
attribute fixes
removing callouts
review fixes
Copy file name to clipboardExpand all lines: modules/op-about-pipelines.adoc
+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
@@ -5,11 +5,11 @@
5
5
[id="about-pipelines_{context}"]
6
6
= Pipelines
7
7
8
-
A _Pipeline_ is a collection of Tasks arranged in a specific order of execution. You can define a CI/CD workflow for your application using Pipelines containing one or more Tasks.
8
+
A _Pipeline_ is a collection of `Task` resources arranged in a specific order of execution. You can define a CI/CD workflow for your application using pipelines containing one or more tasks.
9
9
10
-
A Pipelinedefinition consists of a number of fields or attributes, which together enable the Pipeline to accomplish a specific goal. Each Pipelinedefinition must contain at least one Task, which ingests specific inputs and produces specific outputs. The Pipeline definition can also optionally include Conditions, Workspaces, Parameters, or Resources depending on the application requirements.
10
+
A `Pipeline` resource definition consists of a number of fields or attributes, which together enable the pipeline to accomplish a specific goal. Each `Pipeline` resource definition must contain at least one `Task` resource, which ingests specific inputs and produces specific outputs. The pipeline definition can also optionally include _Conditions_, _Workspaces_, _Parameters_, or _Resources_ depending on the application requirements.
11
11
12
-
The following example shows the `build-and-deploy` Pipeline, which builds an application image from a Git repository using the `buildah` ClusterTask:
12
+
The following example shows the `build-and-deploy` pipeline, which builds an application image from a Git repository using the `buildah` `ClusterTask` resource:
13
13
14
14
[source,yaml]
15
15
----
@@ -30,7 +30,7 @@ spec: <4>
30
30
- name: git-revision
31
31
type: string
32
32
description: revision to be used from repo of the code for deployment
Copy file name to clipboardExpand all lines: modules/op-about-triggers.adoc
+45-25Lines changed: 45 additions & 25 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,21 +5,22 @@
5
5
[id="about-triggers_{context}"]
6
6
= Triggers
7
7
8
-
Use Triggers in conjunction with Pipelines to create a full-fledged CI/CD system where the Kubernetes resources define the entire CI/CD execution. Pipeline Triggers capture the external events and process them to extract key pieces of information. Mapping this event data to a set of predefined parameters triggers a series of tasks that can then create and deploy Kubernetes resources.
8
+
Use _Triggers_ in conjunction with pipelines to create a full-fledged CI/CD system where Kubernetes resources define the entire CI/CD execution. Triggers capture the external events and process them to extract key pieces of information. Mapping this event data to a set of predefined parameters triggers a series of tasks that can then create and deploy Kubernetes resources and instantiate the pipeline.
9
9
10
-
For example, you define a CI/CD workflow using {pipelines-title} for your application. The PipelineRun must start for any new changes to take effect in the application repository. Triggers automate this process by capturing and processing any change events and by triggering a PipelineRun that deploys the new image with the latest changes.
10
+
For example, you define a CI/CD workflow using {pipelines-title} for your application. The pipeline must start for any new changes to take effect in the application repository. Triggers automate this process by capturing and processing any change event and by triggering a pipeline run that deploys the new image with the latest changes.
11
11
12
-
Triggers consist of the following main components that work together to form a reusable, decoupled, and self-sustaining CI/CD system:
12
+
Triggers consist of the following main resources that work together to form a reusable, decoupled, and self-sustaining CI/CD system:
13
13
14
-
* _EventListeners_ provide endpoints, or an event sink, that listen for incoming HTTP-based events with a JSON payload. The EventListener performs lightweight event processing on the payload using Event Interceptors, which identify the type of payload and optionally modify it. Currently, Pipeline Triggers support four types of Interceptors: Webhook Interceptors, GitHub Interceptors, GitLab Interceptors, and Common Expression Language (CEL) Interceptors.
15
-
* _TriggerBindings_ extract the fields from an event payload and store them as parameters.
16
-
* _TriggerTemplates_ specify how to use the parameterized data from the TriggerBindings. A TriggerTemplate defines a resource template that receives input from the TriggerBindings, and then performs a series of actions that result in creation of new PipelineResources and initiation of a new PipelineRun.
14
+
* The `TriggerBinding` resource validates events, extracts the fields from an event payload, and stores them as parameters.
15
+
* The `TriggerTemplate` resource acts as a standard for the way resources must be created. It specifies the way parameterized data from the `TriggerBinding` resource should be used.
16
+
A trigger template receives input from the trigger binding, and then performs a series of actions that results in creation of new pipeline resources, and initiation of a new pipeline run.
17
17
18
-
EventListeners tie the concepts of TriggerBindings and TriggerTemplates together. The EventListener listens for the incoming event, handles basic filtering using Interceptors, extracts data using TriggerBindings, and then processes this data to create Kubernetes resources using TriggerTemplates.
18
+
* The `EventListener` resource provides an endpoint, or an event sink, that listens for incoming HTTP-based events with a JSON payload. It extracts event parameters from each `TriggerBinding` resource, and then processes this data to create Kubernetes resources as specified by the corresponding `TriggerTemplate` resource. The `EventListener` resource also performs lightweight event processing or basic filtering on the payload using event `interceptors`, which identify the type of payload and optionally modify it. Currently, pipeline triggers support four types of interceptors: _Webhook Interceptors_, _GitHub Interceptors_, _GitLab Interceptors_, and _Common Expression Language (CEL) Interceptors_.
19
19
20
+
* The `Trigger` resource connects the `TriggerBinding` and `TriggerTemplate` resources, and this `Trigger` resource is referenced in the `EventListener` specification.
20
21
//image::op-triggers.png[]
21
22
22
-
The following example shows a code snippet of the `vote-app-binding` TriggerBinding, which extracts the Git repository information from the received event payload:
23
+
The following example shows a code snippet of the `TriggerBinding` resource, which extracts the Git repository information from the received event payload:
23
24
24
25
[source,yaml]
25
26
----
@@ -37,13 +38,13 @@ spec:
37
38
value: $(body.head_commit.id)
38
39
----
39
40
40
-
<1> TriggerBinding API version `v1alpha1`.
41
+
<1> The API version of the `TriggerBinding` resource. In this example, `v1alpha1`.
41
42
<2> Specifies the type of Kubernetes object. In this example, `TriggerBinding`.
42
-
<3> Unique name to identify this TriggerBinding.
43
-
<4> List of parameters which will be extracted from the received event payload and passed to the TriggerTemplate. In this example, the Git repository URL, name, and revision are extracted from the body of the event payload.
43
+
<3> Unique name to identify the `TriggerBinding` resource.
44
+
<4> List of parameters which will be extracted from the received event payload and passed to the `TriggerTemplate` resource. In this example, the Git repository URL, name, and revision are extracted from the body of the event payload.
44
45
45
46
46
-
The following example shows a code snippet of a `vote-app-template` TriggerTemplate, which creates Pipeline Resources from the Git repository information received from the TriggerBinding:
47
+
The following example shows a code snippet of a `TriggerTemplate` resource, which creates a pipeline run using the Git repository information received from the `TriggerBinding` resource you just created:
47
48
[source,yaml]
48
49
----
49
50
apiVersion: triggers.tekton.dev/v1alpha1 <1>
@@ -84,14 +85,37 @@ spec:
84
85
claimName: source-pvc
85
86
----
86
87
87
-
<1> TriggerTemplate API version `v1alpha1`.
88
+
<1> The API version of the `TriggerTemplate` resource. In this example, `v1alpha1`.
88
89
<2> Specifies the type of Kubernetes object. In this example, `TriggerTemplate`.
89
-
<3> Unique name to identify this TriggerTemplate.
90
-
<4> Parameters supplied by the TriggerBinding or EventListerner.
91
-
<5> List of Resource templates created for the Pipeline from the parameters received in the TriggerBinding or EventListener.
90
+
<3> Unique name to identify the `TriggerTemplate` resource.
91
+
<4> Parameters supplied by the `TriggerBinding` or `EventListerner` resources.
92
+
<5> List of templates that specify the way resources must be created using the parameters received through the `TriggerBinding` or `EventListener` resources.
92
93
93
94
94
-
The following example shows an EventListener which uses `vote-app-binding` TriggerBinding and `vote-app-template` TriggerTemplate to process incoming events.
95
+
The following example shows a code snippet of a `Trigger` resource, named `vote-trigger` that connects the `TriggerBinding` and `TriggerTemplate` resources.
96
+
97
+
[source,yaml]
98
+
----
99
+
apiVersion: triggers.tekton.dev/v1alpha1 <1>
100
+
kind: Trigger <2>
101
+
metadata:
102
+
name: vote-trigger <3>
103
+
spec:
104
+
serviceAccountName: pipeline <4>
105
+
bindings:
106
+
- ref: vote-app <5>
107
+
template: <6>
108
+
name: vote-app
109
+
----
110
+
<1> The API version of the `Trigger` resource. In this example, `v1alpha1`.
111
+
<2> Specifies the type of Kubernetes object. In this example, `Trigger`.
112
+
<3> Unique name to identify the `Trigger` resource.
113
+
<4> Service account name to be used.
114
+
<5> Name of the `TriggerBinding` resource to be connected to the `TriggerTemplate` resource.
115
+
<6> Name of the `TriggerTemplate` resource to be connected to the `TriggerBinding` resource.
116
+
117
+
118
+
The following example shows an `EventListener` resource, which references the `Trigger` resource named `vote-trigger`.
95
119
96
120
[source,yaml]
97
121
----
@@ -102,14 +126,10 @@ metadata:
102
126
spec:
103
127
serviceAccountName: pipeline <4>
104
128
triggers:
105
-
- bindings: <5>
106
-
- ref: vote-app
107
-
template: <6>
108
-
name: vote-app
129
+
- triggerRef: vote-trigger <5>
109
130
----
110
-
<1> EventListener API version `v1alpha1`.
131
+
<1> The API version of the `EventListener` resource. In this example, `v1alpha1`.
111
132
<2> Specifies the type of Kubernetes object. In this example, `EventListener`.
112
-
<3> Unique name to identify this EventListener.
133
+
<3> Unique name to identify the `EventListener` resource.
113
134
<4> Service account name to be used.
114
-
<5> Name of the TriggerBinding to be used for this EventListener.
115
-
<6> Name of the Triggertemplate to be used for this Eventlistener.
135
+
<5> Name of the `Trigger` resource referenced by the `EventListener` resource.
Copy file name to clipboardExpand all lines: modules/op-adding-triggers.adoc
+51-17Lines changed: 51 additions & 17 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,7 +5,7 @@
5
5
[id="adding-triggers_{context}"]
6
6
= Adding Triggers to a Pipeline
7
7
8
-
Triggers enable Pipelines to respond to external GitHub events, such as push events and pull requests. After you have assembled and started the Pipeline for the application, add TriggerBindings, TriggerTemplates, and an EventListener to capture the GitHub events.
8
+
Triggers enable pipelines to respond to external GitHub events, such as push events and pull requests. After you assemble and start a Pipeline for the application, add the `TriggerBinding`, `TriggerTemplate`, `Trigger`, and `EventListener` resources to capture the GitHub events.
Copy file name to clipboardExpand all lines: modules/op-creating-pipeline-tasks.adoc
+9-8Lines changed: 9 additions & 8 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,39 +8,40 @@
8
8
[discrete]
9
9
.Procedure
10
10
11
-
. Install the `apply-manifests` and `update-deployment` Tasks from the `pipelines-tutorial` repository, which contains a list of reusable Tasks for Pipelines:
11
+
. Install the `apply-manifests` and `update-deployment` `Task` resources from the `pipelines-tutorial` repository, which contains a list of reusable tasks for pipelines:
. Use the `tkn task list` command to list the Tasks you created:
19
+
. Use the `tkn task list` command to list the tasks you created:
19
20
+
20
21
----
21
22
$ tkn task list
22
23
----
23
24
+
24
-
The output verifies that the `apply-manifests` and `update-deployment` Tasks were created:
25
+
The output verifies that the `apply-manifests` and `update-deployment` `Task` resources were created:
25
26
+
26
27
----
27
28
NAME DESCRIPTION AGE
28
29
apply-manifests 1 minute ago
29
30
update-deployment 48 seconds ago
30
31
----
31
32
32
-
. Use the `tkn clustertasks list` command to list the Operator-installed additional ClusterTasks, for example --`buildah` and `s2i-python-3`:
33
+
. Use the `tkn clustertasks list` command to list the Operator-installed additional `ClusterTask` resources, for example --`buildah` and `s2i-python-3`:
33
34
+
34
35
[NOTE]
35
36
====
36
-
You must use a privileged Pod container to run the `buildah` ClusterTask because it requires a privileged security context. To learn more about security context constraints (SCC) for pods, see the Additional resources section.
37
+
You must use a privileged pod container to run the `buildah` `ClusterTask` resource because it requires a privileged security context. To learn more about security context constraints (SCC) for pods, see the Additional resources section.
37
38
====
38
39
+
39
40
----
40
41
$ tkn clustertasks list
41
42
----
42
43
+
43
-
The output lists the Operator-installed ClusterTasks:
44
+
The output lists the Operator-installed `ClusterTask` resources:
0 commit comments