mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 21:46:22 +01:00
Trigger doc updates
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
This commit is contained in:
Preeti
committed by
openshift-cherrypick-robot
openshift-cherrypick-robot
parent
cef64f9b11
commit
7e7fc3edc3
@@ -5,11 +5,11 @@
|
||||
[id="about-pipelines_{context}"]
|
||||
= Pipelines
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
A Pipeline definition consists of a number of fields or attributes, which together enable the Pipeline to accomplish a specific goal. Each Pipeline definition 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.
|
||||
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.
|
||||
|
||||
The following example shows the `build-and-deploy` Pipeline, which builds an application image from a Git repository using the `buildah` ClusterTask:
|
||||
The following example shows the `build-and-deploy` pipeline, which builds an application image from a Git repository using the `buildah` `ClusterTask` resource:
|
||||
|
||||
[source,yaml]
|
||||
----
|
||||
@@ -30,7 +30,7 @@ spec: <4>
|
||||
- name: git-revision
|
||||
type: string
|
||||
description: revision to be used from repo of the code for deployment
|
||||
default: "release-tech-preview-2"
|
||||
default: "release-tech-preview-3"
|
||||
- name: IMAGE
|
||||
type: string
|
||||
description: image to be build from the code
|
||||
|
||||
@@ -5,21 +5,22 @@
|
||||
[id="about-triggers_{context}"]
|
||||
= Triggers
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
Triggers consist of the following main components that work together to form a reusable, decoupled, and self-sustaining CI/CD system:
|
||||
Triggers consist of the following main resources that work together to form a reusable, decoupled, and self-sustaining CI/CD system:
|
||||
|
||||
* _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.
|
||||
* _TriggerBindings_ extract the fields from an event payload and store them as parameters.
|
||||
* _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.
|
||||
* The `TriggerBinding` resource validates events, extracts the fields from an event payload, and stores them as parameters.
|
||||
* 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.
|
||||
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.
|
||||
|
||||
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.
|
||||
* 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_.
|
||||
|
||||
* The `Trigger` resource connects the `TriggerBinding` and `TriggerTemplate` resources, and this `Trigger` resource is referenced in the `EventListener` specification.
|
||||
//image::op-triggers.png[]
|
||||
|
||||
The following example shows a code snippet of the `vote-app-binding` TriggerBinding, which extracts the Git repository information from the received event payload:
|
||||
The following example shows a code snippet of the `TriggerBinding` resource, which extracts the Git repository information from the received event payload:
|
||||
|
||||
[source,yaml]
|
||||
----
|
||||
@@ -37,13 +38,13 @@ spec:
|
||||
value: $(body.head_commit.id)
|
||||
----
|
||||
|
||||
<1> TriggerBinding API version `v1alpha1`.
|
||||
<1> The API version of the `TriggerBinding` resource. In this example, `v1alpha1`.
|
||||
<2> Specifies the type of Kubernetes object. In this example, `TriggerBinding`.
|
||||
<3> Unique name to identify this TriggerBinding.
|
||||
<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.
|
||||
<3> Unique name to identify the `TriggerBinding` resource.
|
||||
<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.
|
||||
|
||||
|
||||
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:
|
||||
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:
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: triggers.tekton.dev/v1alpha1 <1>
|
||||
@@ -89,14 +90,37 @@ spec:
|
||||
storage: 500Mi
|
||||
----
|
||||
|
||||
<1> TriggerTemplate API version `v1alpha1`.
|
||||
<1> The API version of the `TriggerTemplate` resource. In this example, `v1alpha1`.
|
||||
<2> Specifies the type of Kubernetes object. In this example, `TriggerTemplate`.
|
||||
<3> Unique name to identify this TriggerTemplate.
|
||||
<4> Parameters supplied by the TriggerBinding or EventListerner.
|
||||
<5> List of Resource templates created for the Pipeline from the parameters received in the TriggerBinding or EventListener.
|
||||
<3> Unique name to identify the `TriggerTemplate` resource.
|
||||
<4> Parameters supplied by the `TriggerBinding` or `EventListerner` resources.
|
||||
<5> List of templates that specify the way resources must be created using the parameters received through the `TriggerBinding` or `EventListener` resources.
|
||||
|
||||
|
||||
The following example shows an EventListener which uses `vote-app-binding` TriggerBinding and `vote-app-template` TriggerTemplate to process incoming events.
|
||||
The following example shows a code snippet of a `Trigger` resource, named `vote-trigger` that connects the `TriggerBinding` and `TriggerTemplate` resources.
|
||||
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: triggers.tekton.dev/v1alpha1 <1>
|
||||
kind: Trigger <2>
|
||||
metadata:
|
||||
name: vote-trigger <3>
|
||||
spec:
|
||||
serviceAccountName: pipeline <4>
|
||||
bindings:
|
||||
- ref: vote-app <5>
|
||||
template: <6>
|
||||
name: vote-app
|
||||
----
|
||||
<1> The API version of the `Trigger` resource. In this example, `v1alpha1`.
|
||||
<2> Specifies the type of Kubernetes object. In this example, `Trigger`.
|
||||
<3> Unique name to identify the `Trigger` resource.
|
||||
<4> Service account name to be used.
|
||||
<5> Name of the `TriggerBinding` resource to be connected to the `TriggerTemplate` resource.
|
||||
<6> Name of the `TriggerTemplate` resource to be connected to the `TriggerBinding` resource.
|
||||
|
||||
|
||||
The following example shows an `EventListener` resource, which references the `Trigger` resource named `vote-trigger`.
|
||||
|
||||
[source,yaml]
|
||||
----
|
||||
@@ -107,14 +131,10 @@ metadata:
|
||||
spec:
|
||||
serviceAccountName: pipeline <4>
|
||||
triggers:
|
||||
- bindings: <5>
|
||||
- ref: vote-app
|
||||
template: <6>
|
||||
name: vote-app
|
||||
- triggerRef: vote-trigger <5>
|
||||
----
|
||||
<1> EventListener API version `v1alpha1`.
|
||||
<1> The API version of the `EventListener` resource. In this example, `v1alpha1`.
|
||||
<2> Specifies the type of Kubernetes object. In this example, `EventListener`.
|
||||
<3> Unique name to identify this EventListener.
|
||||
<3> Unique name to identify the `EventListener` resource.
|
||||
<4> Service account name to be used.
|
||||
<5> Name of the TriggerBinding to be used for this EventListener.
|
||||
<6> Name of the Triggertemplate to be used for this Eventlistener.
|
||||
<5> Name of the `Trigger` resource referenced by the `EventListener` resource.
|
||||
|
||||
@@ -5,7 +5,7 @@
|
||||
[id="adding-triggers_{context}"]
|
||||
= Adding Triggers to a Pipeline
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
[discrete]
|
||||
.Procedure
|
||||
@@ -27,21 +27,23 @@ spec:
|
||||
value: $(body.head_commit.id)
|
||||
----
|
||||
|
||||
. Create the `TriggerBinding`:
|
||||
. Create the `TriggerBinding` resource:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc create -f <triggerbinding-yaml-file-name.yaml>
|
||||
----
|
||||
+
|
||||
Alternatively, you can create the `TriggerBinding` directly from the `pipelines-tutorial` Git repository:
|
||||
Alternatively, you can create the `TriggerBinding` resource directly from the `pipelines-tutorial` Git repository:
|
||||
+
|
||||
[source,terminal,subs="attributes+"]
|
||||
----
|
||||
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/release-tech-preview-2/03_triggers/01_binding.yaml
|
||||
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/{pipelines-ver}/03_triggers/01_binding.yaml
|
||||
----
|
||||
|
||||
. Copy the content of the following sample `TriggerTemplate` YAML file and save it:
|
||||
+
|
||||
[source,yaml]
|
||||
[source,yaml,subs="attributes+"]
|
||||
----
|
||||
apiVersion: triggers.tekton.dev/v1alpha1
|
||||
kind: TriggerTemplate
|
||||
@@ -53,7 +55,7 @@ spec:
|
||||
description: The git repository url
|
||||
- name: git-revision
|
||||
description: The git revision
|
||||
default: release-tech-preview-2
|
||||
default: {pipelines-ver}
|
||||
- name: git-repo-name
|
||||
description: The name of the deployment to be created / patched
|
||||
|
||||
@@ -88,16 +90,48 @@ spec:
|
||||
+
|
||||
The template specifies a volume claim template to create a persistent volume claim for defining the storage volume for the workspace. Therefore, you do not need to create a persistent volume claim to provide data storage.
|
||||
|
||||
. Create the `TriggerTemplate`:
|
||||
. Create the `TriggerTemplate` resource:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc create -f <triggertemplate-yaml-file-name.yaml>
|
||||
----
|
||||
+
|
||||
Alternatively, you can create the `TriggerTemplate` directly from the `pipelines-tutorial` Git repository:
|
||||
Alternatively, you can create the `TriggerTemplate` resource directly from the `pipelines-tutorial` Git repository:
|
||||
+
|
||||
[source,terminal,subs="attributes+"]
|
||||
----
|
||||
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/release-tech-preview-2/03_triggers/02_template.yaml
|
||||
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/{pipelines-ver}/03_triggers/02_template.yaml
|
||||
----
|
||||
|
||||
. Copy the contents of the following sample `Trigger` YAML file and save it:
|
||||
+
|
||||
[source,yaml]
|
||||
----
|
||||
apiVersion: triggers.tekton.dev/v1alpha1
|
||||
kind: Trigger
|
||||
metadata:
|
||||
name: vote-trigger
|
||||
spec:
|
||||
serviceAccountName: pipeline
|
||||
bindings:
|
||||
- ref: vote-app
|
||||
template:
|
||||
name: vote-app
|
||||
----
|
||||
|
||||
. Create the `Trigger` resource:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc create -f <trigger-yaml-file-name.yaml>
|
||||
----
|
||||
+
|
||||
Alternatively, you can create the `Trigger` resource directly from the `pipelines-tutorial` Git repository:
|
||||
+
|
||||
[source,terminal,subs="attributes+"]
|
||||
----
|
||||
$ oc create -f https://github.com/openshift/pipelines-tutorial/blob/{pipelines-ver}/03_triggers/03_trigger.yaml
|
||||
----
|
||||
|
||||
. Copy the contents of the following sample `EventListener` YAML file and save it:
|
||||
@@ -111,26 +145,26 @@ metadata:
|
||||
spec:
|
||||
serviceAccountName: pipeline
|
||||
triggers:
|
||||
- bindings:
|
||||
- name: vote-app
|
||||
template:
|
||||
name: vote-app
|
||||
- triggerRef: vote-trigger
|
||||
----
|
||||
|
||||
. Create the `EventListener`:
|
||||
. Create the `EventListener` resource:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc create -f <eventlistener-yaml-file-name.yaml>
|
||||
----
|
||||
+
|
||||
Alternatively, you can create the `EvenListener` directly from the `pipelines-tutorial` Git repository:
|
||||
Alternatively, you can create the `EvenListener` resource directly from the `pipelines-tutorial` Git repository:
|
||||
+
|
||||
[source,terminal,subs="attributes+"]
|
||||
----
|
||||
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/release-tech-preview-2/03_triggers/03_event_listener.yaml
|
||||
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/{pipelines-ver}/03_triggers/04_event_listener.yaml
|
||||
----
|
||||
|
||||
. Expose the EventListener service as an {product-title} route to make it publicly accessible:
|
||||
. Expose the `EventListener` service as an {product-title} route to make it publicly accessible:
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
$ oc expose svc el-vote-app
|
||||
----
|
||||
|
||||
@@ -28,7 +28,7 @@ The Pipeline performs the following tasks for the back-end application `vote-api
|
||||
|
||||
. Copy the contents of the following sample Pipeline YAML file and save it:
|
||||
+
|
||||
[source,yaml]
|
||||
[source,yaml,subs="attributes+"]
|
||||
----
|
||||
apiVersion: tekton.dev/v1beta1
|
||||
kind: Pipeline
|
||||
@@ -47,7 +47,7 @@ spec:
|
||||
- name: git-revision
|
||||
type: string
|
||||
description: revision to be used from repo of the code for deployment
|
||||
default: "release-tech-preview-2"
|
||||
default: "{pipelines-ver}"
|
||||
- name: IMAGE
|
||||
type: string
|
||||
description: image to be build from the code
|
||||
@@ -115,8 +115,9 @@ $ oc create -f <pipeline-yaml-file-name.yaml>
|
||||
+
|
||||
Alternatively, you can also execute the YAML file directly from the Git repository:
|
||||
+
|
||||
[source,terminal,subs="attributes+"]
|
||||
----
|
||||
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/release-tech-preview-2/01_pipeline/04_pipeline.yaml
|
||||
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/{pipelines-ver}/01_pipeline/04_pipeline.yaml
|
||||
----
|
||||
|
||||
. Use the `tkn pipeline list` command to verify that the Pipeline is added to the application:
|
||||
|
||||
@@ -8,20 +8,21 @@
|
||||
[discrete]
|
||||
.Procedure
|
||||
|
||||
. Install the `apply-manifests` and `update-deployment` Tasks from the `pipelines-tutorial` repository, which contains a list of reusable Tasks for Pipelines:
|
||||
. Install the `apply-manifests` and `update-deployment` `Task` resources from the `pipelines-tutorial` repository, which contains a list of reusable tasks for pipelines:
|
||||
+
|
||||
[source,terminal,subs="attributes+"]
|
||||
----
|
||||
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/release-tech-preview-2/01_pipeline/01_apply_manifest_task.yaml
|
||||
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/release-tech-preview-2/01_pipeline/02_update_deployment_task.yaml
|
||||
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/{pipelines-ver}/01_pipeline/01_apply_manifest_task.yaml
|
||||
$ oc create -f https://raw.githubusercontent.com/openshift/pipelines-tutorial/{pipelines-ver}/01_pipeline/02_update_deployment_task.yaml
|
||||
----
|
||||
|
||||
. Use the `tkn task list` command to list the Tasks you created:
|
||||
. Use the `tkn task list` command to list the tasks you created:
|
||||
+
|
||||
----
|
||||
$ tkn task list
|
||||
----
|
||||
+
|
||||
The output verifies that the `apply-manifests` and `update-deployment` Tasks were created:
|
||||
The output verifies that the `apply-manifests` and `update-deployment` `Task` resources were created:
|
||||
+
|
||||
----
|
||||
NAME DESCRIPTION AGE
|
||||
@@ -29,18 +30,18 @@ apply-manifests 1 minute ago
|
||||
update-deployment 48 seconds ago
|
||||
----
|
||||
|
||||
. Use the `tkn clustertasks list` command to list the Operator-installed additional ClusterTasks, for example --`buildah` and `s2i-python-3`:
|
||||
. Use the `tkn clustertasks list` command to list the Operator-installed additional `ClusterTask` resources, for example --`buildah` and `s2i-python-3`:
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
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.
|
||||
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.
|
||||
====
|
||||
+
|
||||
----
|
||||
$ tkn clustertasks list
|
||||
----
|
||||
+
|
||||
The output lists the Operator-installed ClusterTasks:
|
||||
The output lists the Operator-installed `ClusterTask` resources:
|
||||
+
|
||||
----
|
||||
NAME DESCRIPTION AGE
|
||||
|
||||
@@ -47,7 +47,7 @@ For {op-system-base-full} version 8, you can install the {pipelines-title} CLI (
|
||||
+
|
||||
[source,terminal]
|
||||
----
|
||||
# subscription-manager repos --enable="pipelines-1.1-for-rhel-8-x86_64-rpms"
|
||||
# subscription-manager repos --enable="pipelines-1.2-for-rhel-8-x86_64-rpms"
|
||||
----
|
||||
|
||||
. Install the `openshift-pipelines-client` package:
|
||||
|
||||
@@ -10,7 +10,7 @@ For Linux distributions, you can download the CLI directly as a `tar.gz` archive
|
||||
|
||||
.Procedure
|
||||
|
||||
. Download the link:https://mirror.openshift.com/pub/openshift-v4/clients/pipeline/0.11.0/tkn-linux-amd64-0.11.0.tar.gz[CLI].
|
||||
. Download the link:https://mirror.openshift.com/pub/openshift-v4/clients/pipeline/0.13.1/tkn-linux-amd64-0.13.1.tar.gz[CLI].
|
||||
|
||||
. Unpack the archive:
|
||||
+
|
||||
|
||||
@@ -10,7 +10,7 @@ For macOS, the `tkn` CLI is provided as a `tar.gz` archive.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Download the link:https://mirror.openshift.com/pub/openshift-v4/clients/pipeline/0.11.0/tkn-macos-amd64-0.11.0.tar.gz[CLI].
|
||||
. Download the link:https://mirror.openshift.com/pub/openshift-v4/clients/pipeline/0.13.1/tkn-macos-amd64-0.13.1.tar.gz[CLI].
|
||||
|
||||
. Unpack and unzip the archive.
|
||||
|
||||
|
||||
@@ -10,7 +10,7 @@ For Windows, the `tkn` CLI is provided as a `zip` archive.
|
||||
|
||||
.Procedure
|
||||
|
||||
. Download the link:https://mirror.openshift.com/pub/openshift-v4/clients/pipeline/0.11.0/tkn-windows-amd64-0.11.0.zip[CLI].
|
||||
. Download the link:https://mirror.openshift.com/pub/openshift-v4/clients/pipeline/0.13.1/tkn-windows-amd64-0.13.1.zip[CLI].
|
||||
|
||||
. Unzip the archive with a ZIP program.
|
||||
|
||||
|
||||
@@ -3,29 +3,31 @@
|
||||
// *openshift_pipelines/creating-applications-with-cicd-pipelines.adoc
|
||||
|
||||
[id="triggering-a-pipeline_{context}"]
|
||||
= Triggering a PipelineRun
|
||||
= Triggering a pipeline run
|
||||
|
||||
Whenever a `push` event occurs in the Git repository, the configured Webhook sends an event payload to the publicly exposed EventListener service route. The EventListener service of the application processes the payload, and passes it to the relevant TriggerBindings and TriggerTemplates pair. The TriggerBinding extracts the parameters and the TriggerTemplate uses these parameters to create resources. This may rebuild and redeploy the application.
|
||||
Whenever a `push` event occurs in the Git repository, the configured Webhook sends an event payload to the publicly exposed `EventListener` service route. The `EventListener` service of the application processes the payload, and passes it to the relevant `TriggerBinding` and `TriggerTemplate` resource pairs. The `TriggerBinding` resource extracts the parameters and the `TriggerTemplate` resource uses these parameters and specifies the way the resources must be created. This may rebuild and redeploy the application.
|
||||
|
||||
In this section, you push an empty commit to the front-end `vote-ui` repository, which then triggers the PipelineRun.
|
||||
In this section, you push an empty commit to the front-end `vote-ui` repository, which then triggers the pipeline run.
|
||||
|
||||
[discrete]
|
||||
.Procedure
|
||||
|
||||
. From the terminal, clone your forked Git repository `vote-ui`:
|
||||
+
|
||||
[source,terminal,subs="attributes+"]
|
||||
----
|
||||
$ git clone git@github.com:<your GitHub ID>/vote-ui.git -b release-tech-preview-2
|
||||
$ git clone git@github.com:<your GitHub ID>/vote-ui.git -b {pipelines-ver}
|
||||
----
|
||||
. Push an empty commit:
|
||||
+
|
||||
[source,terminal,subs="attributes+"]
|
||||
----
|
||||
$ git commit -m "empty-commit" --allow-empty && git push origin release-tech-preview-2
|
||||
$ git commit -m "empty-commit" --allow-empty && git push origin {pipelines-ver}
|
||||
----
|
||||
. Check if the PipelineRun was triggered:
|
||||
. Check if the pipeline run was triggered:
|
||||
+
|
||||
----
|
||||
$ tkn pipelinerun list
|
||||
----
|
||||
+
|
||||
Notice that a new PipelineRun was initiated.
|
||||
Notice that a new pipeline run was initiated.
|
||||
|
||||
@@ -9,4 +9,4 @@
|
||||
//
|
||||
:pipelines-title: Red Hat OpenShift Pipelines
|
||||
:pipelines-shortname: Pipelines
|
||||
:pipelines-ver: 1.0
|
||||
:pipelines-ver: release-tech-preview-3
|
||||
|
||||
Reference in New Issue
Block a user