DevSecOps and Automation on Power

 View Only

Red Hat OpenShift Pipelines as Code on IBM Power

By Lakshmi Daruri posted Mon August 28, 2023 08:58 AM


Red Hat OpenShift Pipelines (OpenShift Pipelines) has played a pivotal role in propelling the CI/CD process forward on Red Hat OpenShift clusters running on IBM Power. Designed on the foundation of Tekton, an adaptable opensource framework for crafting robust CI/CD systems, OpenShift Pipelines empowers developers to swiftly build, test, and deploy applications across various cloud providers and on-premises setups.

Over time, Tekton has seen upgrades and additions to its features, including CLI, triggers, operators, chains, hub, and more. These features have been integrated into RedHat OpenShift Pipelines.

Pipelines as Code on IBM Power

Introducing Pipelines as Code, or PAC, a recent addition to the arsenal of Tekton/OpenShift Pipelines features. The question arises: With an array of existing OpenShift Pipelines features that already handle automation in the CI/CD realm, why introduce yet another feature? This blog endeavors to answer this question while shedding light on the essence of Pipelines as Code. We'll delve deeper and address the following queries in this blog and a series of future blogs about PAC:

  • How can we synergize the potential of Git repositories with OpenShift Pipelines/Tekton?
  • How can we define Tekton templates inside the source code repositories?
  • How does a simple Push/Pull Request (PR) on Git repositories trigger OpenShift Pipelines?

Now that we have set the tone for this blog series, let's formally acquaint ourselves with Pipelines as Code and showcase some practical examples using Git repositories like GitHub, GitLab, Bitbucket, and the Red Hat OpenShift cluster on IBM Power.


Pipelines as Code or PAC defines Tekton templates within the source code repository. By leveraging PAC, we can streamline the CI/CD process using simple configurations. With Tekton, we can craft a YAML file containing code to orchestrate Pipelines. A straightforward commit or Pull Request serves as the trigger for executing this Pipelines code, cascading its execution from Git repositories to the Red Hat OpenShift cluster. Moreover, PAC facilitates seamless navigation between Git repositories and OpenShift clusters.

Let’s explore some of the useful features of OpenShift Pipelines as Code:

  • Ship code and pipelines, all in the same repository: Developers can bundle Pipelines configurations alongside application code in the same repository. PAC seamlessly updates and deploys Pipelines on the Red Hat OpenShift cluster.
  • UI sweetness, and user happiness: PAC boasts native integration with Git repositories such as GitHub, Bitbucket, and GitLab. This integration allows you to monitor Pipelines execution history directly within the Git repository's UI. Additionally, direct links to execution logs within the Red Hat OpenShift cluster are provided.
  • Modern Git repo workflow: During Pull Requests, if a re-run of the pipeline is required without generating a new commit, a simple PR in GitHub triggers a fresh pipeline execution and captures the results.

Now, let's embark on a step-by-step journey of implementing PAC.


The following prerequisites apply for implementing PAC across all Git repositories.

  1. Ensure the OpenShift Pipelines operator is installed on your cluster. For more information, refer to Set up pipelines with the help of Red Hat OpenShift Pipelines on
  2. Ensure the Tekton CLI tool tkn is installed on your machine. For more information, refer to pipeline on
  3. Ensure the Tekton PAC CLI tool tkn pac is installed on your machine. For more information, refer to Pipelines as Code version v0.19.4 on GitHub.
  4. Set up a new project on the cluster using the command ‘oc new-project <project-name>’.
    For example: ‘oc new-project pac-191’.
  5. Acquire a webhook forwarder/relayer by using the smee.

Note: In case an application requires the capability to respond to requests, a mechanism to expose the localhost to the internet becomes imperative. Similarly, for establishing connectivity to internet-based repositories, a service that facilitates the direct exposure of your OpenShift cluster on Power to the internet is essential, given that they operate within the IBM Domain.

For the implementation of a webhook forwarder, we opt for smee - a compact service employing Server-Sent events to act as an intermediary for payloads sourced from the webhook. These payloads are subsequently transmitted to the locally running application.

To set up the gosmee deployment on the OpenShift cluster, leveraging the smee link, we enable the service to be accessible within the local network through public service URLs.

The following diagram depicts this configuration.

Gosmee configuration

Initiate gosmee deployment

  1. The creation of a gosmee deployment requires the generation of a smee URL. This can be accomplished by clicking on this smee URL.
    It generates a random link, for example:
  2. Use the following YAML template to create a gosmee deployment:
    apiVersion: apps/v1
    kind: Deployment
      name: gosmee
      namespace: <namespace>
      replicas: 1
          app: gosmee
            app: gosmee
            - image:
              imagePullPolicy: IfNotPresent
              name: gosmee
        type: RollingUpdate
          maxUnavailable: 25%
          maxSurge: 25%
      revisionHistoryLimit: 10
      progressDeadlineSeconds: 600

    Note: Replace <namespace> with <your project name > on the cluster, for example: ‘pac-191’ and <smeeurl> with a new smee URL generated as demonstrated in step 2.
    For example:
  3. Create gosmee deployment on the cluster. It creates a gosmee pod running on the cluster.
    # oc create -f Deployment.yaml
    Create gosmee deployment.

PAC architectural diagram

The architectural diagram provides a visual representation of the fundamental structure of the PAC system. The following diagram illustrates the key components and their interactions within the PAC framework.

PAC architectural diagram.

Steps for implementing Red Hat OpenShift Pipelines as Code

The process to bootstrap the PAC application may vary among GitHub, GitLab, and Bitbucket platforms. Here are the general steps to implement PAC.

  1. Log in to your Git repository (GitHub or GitLab) and create an access token (or app password for Bitbucket).
  2. Connect to the OpenShift cluster.
  3. Apply the gosmee deployment to your OpenShift cluster.
  4. Clone your application repository to a local folder.
  5. Create a PAC repository from your application using the ‘tkn pac create repo’ command, providing necessary details like namespace, access token, and webhook URL.
    Customize the generated 'pipelinerun.yaml’ file inside the '.tekton' folder if needed.
  6. Commit and push the changes to the remote Git repository.
  7. Raise a Pull Request or commit to the master branch of the repository to trigger a pipeline in the Git repository and start a pipelinerun in the OpenShift cluster via the webhook controller.


In conclusion, this blog has served as an introduction to the Pipelines as Code feature. While we addressed fundamental queries about PAC, we also offered a comprehensive outline of the step-by-step procedure to configure PAC with application Git repositories. With the groundwork laid, you're likely eager to witness a functional PAC demonstration. Stay tuned for upcoming blog entries where we'll walk you through PAC demos with GitHub, GitLab, and Bitbucket on the Red Hat OpenShift cluster on Power. Your journey continues, so keep following along. Stay tuned!