Triggers in OpenShift Pipeline for polling
Here in this blog, we are going to learn triggers in OpenShift Pipeline for Polling.
A polling trigger, or event that periodically checks your Git repository for new changes, is what poll-based change detection is. You will learn how to set up polling triggers in OpenShift Pipelines (Tekton) in a limited network in this post.
Pull-based trigger workflow.
In essence, webhooks are a push-based workflow, whereas polling triggers are pull-based. In other words, webhooks react to a push of changes from the repository, whereas polling triggers periodically launch an event over an interval to check if there is any change.
Repository Mirroring (which mirrors all changes over an interval with another repository) can be used to configure the polling triggers for your pipeline CI/CD if you have a private GitLab repository in your isolated network. Webhooks are often activated via push events.
GitLab is overkill for some use situations, though, so you should utilize CronJob with Bash scripts to build polling triggers. Option 2 in the diagram up top demonstrates this.
Using CronJob, polling triggers
For testing a pipeline run using Creating CI/CD solutions for apps using OpenShift Pipelines, I generated the following example application. For the sake of the easier tests in this part, I skipped a secret token configuration in the Trigger YAML. Security wouldn’t be an issue on a constrained network.
Replace the GitHub repository listed above with the one you forked from the front-end pipelines-vote-ui for your tests after making sure the sample application pipelines-vote-ui is functioning properly (in my instance, https://github.com/bysnupy/pipelines-vote-ui). In the next demonstration, I’ll make a modification to my repository to see if the pipeline starts or not.
Let’s examine the specifics of the ensuing resources to use scripts to construct basic polling triggers. The fundamental logic to determine triggering the pipeline is as simple as comparing the previous and current revision sha256 hash values using the git command, and the most recent sha256 hash would be kept in a PV volume for the following checks. For the purpose of starting a pipeline, the CronJob uses the curl command to send a push event request to an EventListener on behalf of the GitHub repository webhook.
We may reuse current trigger binding and trigger template resources thanks to this strategy. Regardless, you might want to think about switching from CronJob’s curl command to the tkn CLI for your requirements. More than just the curl command can be altered using the tkn CLI in your pipeline flow.
Please see Webhook events and payloads for more information on GitHub webhook HTTP POST payloads for changing curl parameters.
utilizing polling triggers to start a pipeline operation
The aforementioned polling triggers are activated when a change event happens in the Git repository. It is routinely checked by CronJob. Send an event payload (JSON data) to the privately exposed EventListener service using the curl command after becoming aware of fresh data. The payload is processed by the application’s EventListener service before being forwarded to the appropriate TriggerBinding and TriggerTemplate resource pairs. The TriggerTemplate resource uses these parameters and describes how to generate the resources after the TriggerBinding resource extracts the parameters. The application may be rebuilt and redeployed throughout this process.
In order to start the pipeline, you submit an empty commit to the front-end pipelines-vote-ui repository in this part.
Wrap up
This post illustrated and confirmed the use of CronJob for polling triggers. Additionally, you can alter the logic to suit your particular needs. For example, you could use the tkn command to run the pipeline directly without needing an EventListener. You can accomplish anything you need to using your own implementation. With this understanding, I hope you can better understand the OpenShift Pipeline.
