#Introduction

Pipelines-as-Code (PAC) lets you keep Tekton pipeline definitions next to your application code, in the same Git repository, and have them executed automatically when a Git event matches. Instead of editing PipelineRuns in the cluster, you commit them under a .tekton/ directory; PAC reads the right manifest on the right branch and creates the PipelineRun for you.

#Who this documentation is for

• Cluster administrators deploy and maintain the PAC component, expose it to Git providers, and configure cluster-wide settings.
• Project users create Repository resources, set up the per-repository or per-organization Git integration, and write the PipelineRuns committed under .tekton/.

The Install chapter is administrator-focused. The Guides and How To chapters are user-focused.

#Core capabilities

• Per-repository integration through a single Repository Kubernetes resource that references the Git URL and (in Webhook mode) a Secret with the access token.
• Git event matching — push, pull request / merge request, tag push, commit comment, issue comment.
• PipelineRun selection through annotations on the PipelineRun manifest (on-event, on-target-branch, on-cel-expression, on-path-change and others).
• Status reporting back to the Git provider, surfaced as GitHub Checks or commit statuses, with a link back to the cluster.
• Comment-driven actions — /retest, /cancel, custom commands defined on the PipelineRun.
• GitHub and GitLab integration — GitHub App, GitHub Webhook, and GitLab Webhook workflows are covered in this documentation.
• Resolver integration — pull tasks from Tekton Hub, remote Git URLs, or other resolvers without bundling them in the repository.

#How it works

PAC consists of three controller-side components and one Kubernetes resource:

1. Repository resource — a namespaced pipelinesascode.tekton.dev/v1alpha1 resource that binds a Git repository URL to its credentials (Webhook mode) or to nothing at all (GitHub App mode, where credentials are cluster-wide).
2. PAC Webhook — the HTTP receiver that the Git provider posts events to. It verifies the signature using the webhook.secret value shared with the provider.
3. PAC Controller — looks up the matching Repository, fetches the PipelineRun manifests from .tekton/ on the relevant ref, filters them through the annotation grammar, and creates the PipelineRun in the Repository's namespace.
4. PAC Watcher — observes the PipelineRun and reports completion (and intermediate steps where the provider supports it) back to the Git provider.

The full sequence is covered in Core Concepts.

#Prerequisites for using PAC

Infrastructure:

• A Kubernetes cluster with the Tekton Operator installed.
• The PAC component deployed and exposed to the Internet or to the network that hosts your Git provider; see Manage PAC Component.
• kubectl access to the namespace where you intend to run pipelines.

Knowledge:

• Tekton basics — Pipeline, PipelineRun, Task, TaskRun.
• Kubernetes basics — namespaces, Secrets, custom resources.
• Familiarity with the Git provider you will integrate, such as GitHub or GitLab.

#Where to go next

• First time — start with Quick Start for an end-to-end minimal example.
• Setting up a real repository — pick the matching guide under Guides.
• Understanding the resources — read Core Concepts.
• Component deployment — Manage PAC Component.
• Troubleshooting — Common Issues.

#Related documentation

• Define PipelineRuns in Git — define and version PipelineRuns under .tekton/.
• Trigger Pipelines — how Git operations map to events.