Installation on Pipelines as Code

Overview

Mon, 01 Jan 0001 00:00:00 +0000

Pipelines-as-Code - Installation #

Pipelines-as-Code support different installation method to Git provider platforms (i.e: GitHub, Bitbucket and so on)

The preferred method to use Pipelines-as-Code is configured with a GitHub Application.

Install Pipelines-as-Code infrastructure #

To get started with Pipelines-as-Code, you need to

Install Pipelines-as-Code.
- If you run on OpenShift Pipelines (from 1.7.x) Pipelines-as-Code should be automatically installed
- If you want to do a manual install you can follow the installation guide.
Configure your Git Provider (eg: a GitHub Application) to access Pipelines as Code.

Git Provider Setup #

After installing Pipelines-as-Code you are now ready to configure your Git provider. Choose your preferred install method, if you don’t have any preferences the preferred install method is the GitHub Application method.

Getting started guide.

Mon, 01 Jan 0001 00:00:00 +0000

Getting started with Pipelines-as-Code #

This guide will walk you through the process of getting started with Pipelines-as-Code.

This will start with the installation of Pipelines-as-Code on your cluster, then the creation of a GitHub Application, the creation of a Repository CR to specify which repository you want to use with Pipelines-as-Code, and finally, we are going to create a simple Pull Request to test that configuration and see how the Pipelines-as-Code flow looks like.

Installation Through Operator

Mon, 01 Jan 0001 00:00:00 +0000

Installation Through Operator #

The easiest way to install Pipelines-as-Code on OpenShift is with the Red Hat OpenShift Pipelines Operator.

On the OpenShift Pipelines Operator, the default namespace is openshift-pipelines.

Note:

When Pipelines-as-Code is installed through the Tekton Operator the configuration of Pipelines-as-Code is controlled by TektonConfig Custom Resource. That means Tekton Operator will revert the configuration changes done directly on pipeline-as-code configmap or OpenShiftPipelinesAsCode custom resource.

The default configurations for Pipelines-as-Code in TektonConfig looks like below. Note that since version v0.37.0, Pipelines-as-Code defaults to using Artifact Hub rather than Tekton Hub. Tekton Hub is deprecated and will be removed in a future version. You can still use the public tekton hub instance by explicitly prefixing your task with tektonhub://

Manual Installation

Mon, 01 Jan 0001 00:00:00 +0000

Installation #

Operator Install #

Follow Operator Installation to install Pipelines As Code on OpenShift.

Manual Install #

Prerequisite #

Before installing Pipelines As Code, please verify tektoncd/pipeline is installed. You can install the latest released version using the following command

  kubectl apply --filename https://storage.googleapis.com/tekton-releases/pipeline/latest/release.yaml

If you are not installing the most recent version, ensure that you have Tekton Pipeline installed and running at a version that is higher than v0.44.0.

If you want to do a manual installation of the stable release of Pipelines-as-Code on your OpenShift cluster you can apply the template with kubectl :

Settings

Mon, 01 Jan 0001 00:00:00 +0000

Pipelines-as-Code configuration settings #

There is a few things you can configure through the config map pipelines-as-code in the pipelines-as-code namespace.

application-name

The name of the application for example when showing the results of the PipelineRun. If you’re using the GitHub App you will need to customize the label on the github app setting as well. . Default to Pipelines-as-Code CI
secret-auto-create

Whether to auto create a secret with the token generated through the GitHub application to be used with private repositories. This feature is enabled by default.

Custom certificates

Mon, 01 Jan 0001 00:00:00 +0000

Custom certificates #

If you need to configure Pipelines-as-Code with a Git repository that requires a privately signed or custom certificate to access, then you will need to expose the certificate to Pipelines-as-Code.

OpenShift #

If you have installed Pipelines-as-Code through the OpenShift Pipelines operator, then you will need to add your custom certificate to the cluster via the Proxy object. The operator will expose the certificate in all OpenShift Pipelines components and workloads, including Pipelines-as-Code.

Global Repository Settings

Mon, 01 Jan 0001 00:00:00 +0000

Global repository settings is a Technology Preview feature only. Technology Preview features are not currently supported and might not be functionally complete. We do not recommend using them in production. These features provide early access to an upcoming Pipelines-as-Code features, enabling you to test functionality and provide feedback during the development process.

Pipelines-as-Code Global Repository Settings #

Pipelines-as-Code lets you have a global repository for settings of all your local repositories. This enables you to define settings that will be applied to all local repositories on your cluster.

Logging

Mon, 01 Jan 0001 00:00:00 +0000

Logging Configuration #

Pipelines-as-Code uses a ConfigMap named pac-config-logging in its namespace (by default, pipelines-as-code) to configure the logging behavior of its controllers.

To view the ConfigMap, use the following command:

kubectl get configmap pac-config-logging -n pipelines-as-code

To see the full content of the ConfigMap, run:

kubectl get configmap pac-config-logging -n pipelines-as-code -o yaml

The data section of the ConfigMap contains the following keys:

loglevel.pipelinesascode: The log level for the pipelines-as-code-controller component.
loglevel.pipelines-as-code-webhook: The log level for the pipelines-as-code-webhook component.
loglevel.pac-watcher: The log level for the pipelines-as-code-watcher component.

You can change the log level from info to debug or any other supported value. For example, to set the log level for the pipelines-as-code-watcher to debug, run:

GitHub Apps

Mon, 01 Jan 0001 00:00:00 +0000

Create a Pipelines-as-Code GitHub App #

The GitHub App install is different from the other install methods since it acts as the integration point with OpenShift Pipelines and brings the Git workflow into Tekton pipelines. You only need one GitHub App for every user on the cluster usually setup by the admin.

You need the webhook of the GitHub App to point to your Pipelines-as-Code Controller route or ingress endpoint which would listen to GitHub events.

GitHub Webhook

Mon, 01 Jan 0001 00:00:00 +0000

Use Pipelines-as-Code with GitHub Webhook #

If you are not able to create a GitHub application you can use Pipelines-as-Code with GitHub Webhook on your repository.

Using Pipelines-as-Code through GitHub webhook does not give you access to the GitHub CheckRun API, therefore the status of the tasks will be added as a Comment on the PullRequest and not through the Checks Tab.

gitops comment (ie: /retest /ok-to-test) with GitHub webhook is not supported. If you need to restart the CI you will need to generate a new commit. You can make it quick with this command line snippet (adjust branchname to the name of the branch) :

GitLab

Mon, 01 Jan 0001 00:00:00 +0000

Use Pipelines-as-Code with GitLab Webhook #

Pipelines-As-Code supports on GitLab through a webhook.

Follow the pipelines-as-code installation according to your Kubernetes cluster.

Create GitLab Personal Access Token #

Follow this guide to generate a personal token as the manager of the Org or the Project:

https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html

Note: You can create a token scoped only to the project. Since the token needs to be able to have api access to the forked repository from where the MR come from, it will fail to do it with a project scoped token. We try to fallback nicely by showing the status of the pipeline directly as comment of the Merge Request.

Bitbucket Cloud

Mon, 01 Jan 0001 00:00:00 +0000

Use Pipelines-as-Code with Bitbucket Cloud #

Pipelines-As-Code supports on Bitbucket Cloud through a webhook.

Follow the Pipelines-As-Code installation according to your Kubernetes cluster.

Create Bitbucket Cloud App Password #

Follow this guide to create an app password:

https://support.atlassian.com/bitbucket-cloud/docs/app-passwords/

Check these boxes to add the permissions to the token:

Account: Email, Read
Workspace membership: Read, Write
Projects: Read, Write
Issues: Read, Write
Pull requests: Read, Write

NOTE: If you are going to configure webhook through CLI, you must also add additional permission

Bitbucket Data Center

Mon, 01 Jan 0001 00:00:00 +0000

Install Pipelines-As-Code on Bitbucket Data Center #

Pipelines-As-Code has a full support of Bitbucket Data Center.

After following the installation:

You will have to generate a personal token as the manager of the Project, follow the steps here:

https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html

The token will need to have the PROJECT_ADMIN and REPOSITORY_ADMIN permissions.

Note that the token needs to be able to have access to the forked repository in pull requests, or it would not be able to process and access the pull request.

Metrics

Mon, 01 Jan 0001 00:00:00 +0000

Metrics Overview #

The metrics for pipelines-as-code can be accessed through the pipelines-as-code-watcher service on port 9090.

pipelines-as-code supports various exporters, such as Prometheus, Google Stackdriver, and more. You can configure these exporters by referring to the observability configuration.

Name	Type	Labels/Tags	Description
`pipelines_as_code_git_provider_api_request_count`	Counter	`provider`=<git_provider> `event-type`=<event_type> `namespace`=<pipelinerun_namespace> `repository`=<repository_cr_name>	Number of API requests submitted to git providers
`pipelines_as_code_pipelinerun_count`	Counter	`provider`=<git_provider> `event-type`=<event_type> `namespace`=<pipelinerun_namespace> `repository`=<repository_cr_name>	Number of pipelineruns created by pipelines-as-code
`pipelines_as_code_pipelinerun_duration_seconds_sum`	Counter	`namespace`=<pipelinerun_namespace> `repository`=<repository_cr_name> `status`=<pipelinerun_status> `reason`=<pipelinerun_status_reason>	Number of seconds all pipelineruns have taken in pipelines-as-code
`pipelines_as_code_running_pipelineruns_count`	Gauge	`namespace`=<pipelinerun_namespace> `repository`=<repository_cr_name>	Number of running pipelineruns in pipelines-as-code

Note: The metric pipelines_as_code_git_provider_api_request_count is emitted by both the Controller and the Watcher, since both services use Git providers’ APIs. When analyzing this metric, you may need to combine both services’ metrics. For example, using PromQL:

Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Kubernetes #

Pipelines-as-Code works on kubernetes/minikube/kind.

Prerequisites #

You will need to pre-install the pipeline release.yaml file on your kubernetes cluster.

You will need at least a kubernetes version greater than 1.23

Install #

The release YAML to install pipelines are for the released version :

kubectl apply -f https://raw.githubusercontent.com/openshift-pipelines/pipelines-as-code/stable/release.k8s.yaml

and for the nightly :

kubectl apply -f https://raw.githubusercontent.com/openshift-pipelines/pipelines-as-code/nightly/release.k8s.yaml

Verify #

Ensure that the pipelines-as-code controller, webhook, and watcher have come up healthy, for example:

Multiple GitHub Applications Support

Mon, 01 Jan 0001 00:00:00 +0000

Multi-GitHub Application Configuration #

Multi-GitHub Apps Support is a Technology Preview feature only. Technology Preview features are not currently supported and might not be functionally complete. We do not recommend using them in production. These features provide early access to an upcoming Pipelines-as-Code features, enabling you to test functionality and provide feedback during the development process.

Pipelines-as-Code allows multiple GitHub applications to operate on the same cluster, enabling integration with different GitHub instances (e.g., public GitHub and GitHub Enterprise Server).