/Recent content in An opinionated CI based on OpenShift Pipelines / Tekton on Pipelines as CodeHugo -- gohugo.ioen-us/docs/install/overview/Mon, 01 Jan 0001 00:00:00 +0000/docs/install/overview/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 # Pipelines-as-Code support different installation method to Git provider platforms (ie: GitHub, Bitbucket and so on) The preferred method to use Pipelines-as-Code is configured with a GitHub Application. To get started with Pipelines-as-Code, you need to/docs/flows/diagram/Mon, 01 Jan 0001 00:00:00 +0000/docs/flows/diagram/Diagram of a Pull/Merge Request Flow #/docs/guide/repositorycrd/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/repositorycrd/Repository CR # The Repository CR serves the following purposes: Informing Pipelines-as-Code that an event from a specific URL needs to be handled. Specifying the namespace where the PipelineRuns will be executed. Referencing an API secret, username, or API URL if necessary for Git provider platforms that require it (e.g., when using webhooks instead of the GitHub application). Providing the last PipelineRun statuses for the repository (5 by default)./docs/flows/concurrency/Mon, 01 Jan 0001 00:00:00 +0000/docs/flows/concurrency/Concurrency Flow # mermaid.initialize({ "flowchart": { "useMaxWidth":true }, "theme": "default" } ) graph TD A1[Controller] -- B1(Validate & Process Event) B1 -- C1{Is concurrency defined?} C1 --|Not Defined| D1[Create PipelineRun with state='started'] C1 --|Defined| E1[Create PipelineRun with pending status and state='queued'] Z[Pipelines-as-Code] A[Watcher] -- B(PipelineRun Reconciler) B -- C{Check state} C -- |completed| F(Return, nothing to do!) C -- |queued| D(Create Queue for Repository) C -- |started| E{Is PipelineRun Done?/docs/install/getting-started/Mon, 01 Jan 0001 00:00:00 +0000/docs/install/getting-started/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./docs/install/operator_installation/Mon, 01 Jan 0001 00:00:00 +0000/docs/install/operator_installation/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 configurations of Pipelines-as-Code is controlled by TektonConfig Custom Resource. That means Tekton Operator will revert the configurations changes done directly on pipeline-as-code configmap or OpenShiftPipelinesAsCode custom resource. The default configurations for Pipelines-as-Code in TektonConfig looks like below/docs/install/installation/Mon, 01 Jan 0001 00:00:00 +0000/docs/install/installation/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./docs/guide/resolver/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/resolver/Pipelines-as-Code resolver # The Pipelines-as-Code resolver ensures that the PipelineRun you are running doesn’t conflict with others. Pipelines-as-Code parses any files ending with a .yaml or .yml suffix in the .tekton directory and subdirectory at the root of your repository. It will automatically attempt to detect any Tekton resources like Pipeline, PipelineRun, Task. When detecting a PipelineRun it will try to resolve it as a single PipelineRun with an embedded PipelineSpec of the referenced Task or Pipeline./docs/guide/authoringprs/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/authoringprs/Authoring PipelineRuns in .tekton/ directory # Pipelines-as-Code will always try to be as close to the Tekton template as possible. Usually, you will write your template and save them with a .yaml extension, and Pipelines-as-Code will run them. The .tekton directory must be at the top level of the repo. You can reference YAML files in other repos using remote URLs (see Remote HTTP URLs for more information), but PipelineRuns will only be triggered by events in the repository containing the ./docs/guide/matchingevents/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/matchingevents/Matching a PipelineRun to a Git provider Event # A PipelineRun can be matched to a Git provider event by using specific annotations in the PipelineRun metadata. For example, when you have these as metadata in your PipelineRun: metadata: name: pipeline-pr-main annotations: pipelinesascode.tekton.dev/on-target-branch: "[main]" pipelinesascode.tekton.dev/on-event: "[pull_request]" Pipelines-as-Code will match the PipelineRun pipeline-pr-main if the Git provider events target the branch main and it’s coming from a [pull_request]/docs/install/settings/Mon, 01 Jan 0001 00:00:00 +0000/docs/install/settings/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./docs/install/certs/Mon, 01 Jan 0001 00:00:00 +0000/docs/install/certs/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./docs/install/global_repositories_setting/Mon, 01 Jan 0001 00:00:00 +0000/docs/install/global_repositories_setting/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./docs/guide/running/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/running/Running the PipelineRun # Pipelines-as-Code (PAC) can be used to run pipelines on events such as pushes or pull requests. When an event occurs, PAC will try to match it to any PipelineRuns located in the .tekton directory of your repository that are annotated with the appropriate event type. The PipelineRuns definitions are fetched from the .tekton directory at the root of your repository from where the event comes from, this is unless you have configured the provenance from the default branch on your Repository CR./docs/guide/gitops_commands/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/gitops_commands/GitOps Commands # Pipelines-as-Code supports the concept of GitOps commands, which allow users to issue special commands in a comment on a Pull Request or a pushed commit to control Pipelines-as-Code. The advantage of using a GitOps command is that it provides a journal of all the executions of your pipeline directly on your Pull Request, near your code. GitOps Commands on Pull Requests # For example, when you are on a Pull Request, you may want to restart all your PipelineRuns./docs/guide/statuses/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/statuses/Status # GitHub apps # After the PipelineRun has finished, its status will be shown in the GitHub Check tabs, along with a concise overview of the status the name and the duration of each task in the pipeline. If the task has a displayName it will use it as the description of the task or otherwise just the task name. If any step fails, a small portion of the log from that step will also be included in the output./docs/guide/privaterepo/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/privaterepo/Private repositories # Pipelines-as-Code allows the use of private repositories by creating or updating a secret in the target namespace. This secret contains the user token required for the git-clone task to clone private repositories. Whenever Pipelines-as-Code creates a new PipelineRun in the target namespace, it also creates a secret with a specific name format: pac-gitauth-REPOSITORY_OWNER-REPOSITORY_NAME-RANDOM_STRING This secret contains a Git Config file named .gitconfig and a Git credentials file named ./docs/guide/cleanups/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/cleanups/PipelineRuns Cleanups # There can be many PipelineRuns into a user namespace and Pipelines-as-Code has the ability to only keep a certain amount of PipelineRuns and cleaning the old ones. When your PipelineRun has this annotation : pipelinesascode.tekton.dev/max-keep-runs: "maxNumber" Pipelines-as-Code sees this and will start cleaning up right after one of the PipelineRun finishes to a successful execution keeping only the last maxNumber of PipelineRuns. It will skip the Running or Pending PipelineRuns but will not skip the PipelineRuns with Unknown status./docs/install/github_apps/Mon, 01 Jan 0001 00:00:00 +0000/docs/install/github_apps/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./docs/install/github_webhook/Mon, 01 Jan 0001 00:00:00 +0000/docs/install/github_webhook/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./docs/install/gitlab/Mon, 01 Jan 0001 00:00:00 +0000/docs/install/gitlab/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./docs/install/bitbucket_cloud/Mon, 01 Jan 0001 00:00:00 +0000/docs/install/bitbucket_cloud/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/docs/install/bitbucket_datacenter/Mon, 01 Jan 0001 00:00:00 +0000/docs/install/bitbucket_datacenter/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./docs/install/metrics/Mon, 01 Jan 0001 00:00:00 +0000/docs/install/metrics/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 Description pipelines_as_code_pipelinerun_count Counter Number of pipelineruns created by pipelines-as-code pipelines_as_code_pipelinerun_duration_seconds_sum Counter Number of seconds all pipelineruns have taken in pipelines-as-code pipelines_as_code_running_pipelineruns_count Gauge Number of running pipelineruns in pipelines-as-code/docs/install/kubernetes/Mon, 01 Jan 0001 00:00:00 +0000/docs/install/kubernetes/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:/docs/guide/customparams/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/customparams/Custom Parameters # Using the {{ param }} syntax, Pipelines-as-Code lets you expand a variable or the payload body inside a template within your PipelineRun. By default, several variables are exposed according to the event. To view all the variables exposed by default, refer to the documentation on Authoring PipelineRuns. With the custom parameter, you can specify some custom values to be replaced inside the template. Utilizing the Tekton PipelineRun parameters feature may generally be the preferable approach, and custom params expansion should only be used in specific scenarios where Tekton params cannot be used./docs/guide/incoming_webhook/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/incoming_webhook/Incoming webhook # Pipelines-as-Code support the concept of incoming webhook URL. It let you trigger PipelineRun in a Repository using a shared secret and URL, instead of creating a new code iteration. Incoming Webhook URL # To use incoming webhooks in Pipelines-as-Code, you must configure the incoming field in your Repository CRD. This field references a Secret, which serves as the shared secret, as well as the branches targeted by the incoming webhook./docs/guide/policy/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/policy/Policy on Pipelines-as-Code Actions # Pipelines-as-Code uses policies to control which actions can be performed by users who belong to specific teams within an organization, as defined on GitHub or other supported Git providers (currently GitHub and Gitea). This feature is supported on the following providers Git Provider Supported GitHub App ✅️ GitHub Webhook ✅️ Gitea ✅️ GitLab ❌️ Bitbucket Cloud ❌️ Bitbucket Data Center ❌️ Supported Actions # pull_request - This action triggers the CI in Pipelines-as-Code./docs/guide/cli/Mon, 01 Jan 0001 00:00:00 +0000/docs/guide/cli/Pipelines-as-Code CLI # Pipelines-as-Code provides a powerful CLI designed to work as a plug-in to the Tekton CLI (tkn). tkn pac allows you to: bootstrap: quickly bootstrap a Pipelines-as-Code installation. create: create a new Pipelines-as-Code Repository definition. delete: delete an existing Pipelines-as-Code Repository definition. generate: generate a simple pipelinerun to get you started with Pipelines-as-Code. list: list Pipelines-as-Code Repositories. logs: show the logs of a PipelineRun from a Repository CRD./docs/install/second_controller/Mon, 01 Jan 0001 00:00:00 +0000/docs/install/second_controller/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./docs/blog/release-osp-1.15/Mon, 01 Jan 0001 00:00:00 +0000/docs/blog/release-osp-1.15/OpenShift Pipelines 1.15 presents several new enhancements to Pipelines-as-Code. Below are the key updates. Much improved GitOps Commands # These commands allow you to make quick comments on a pull request to restart a PipelineRun through Pipelines-as-Code. Commonly used commands include /test pipelinerun to rerun a specific pipelinerun, or /retest to rerun all PipelineRuns. Trigger PipelineRuns Irrespective of Annotations # Previously, to re-trigger PipelineRuns, they had to match specific annotations such as pipelinesascode./docs/dev/release-process/Mon, 01 Jan 0001 00:00:00 +0000/docs/dev/release-process/Release process for Pipelines-as-Code # Clear out the PR needed to be merged. Wait that CI is connected. Verify PAC CI cluster is up. Verify that you have gpg signing setup for your commits. Prepare to tag the release with a version, you need to choose between a major release/minor or patch release. If for example you choose to do the release 1.