Tekton can fetch your pipelines not just from local files, but from remote Git repositories or OCI-compliant artifact bundles.
Let’s see it in action. Imagine you have a pipeline definition in a Git repository. Instead of kubectl apply -f pipeline.yaml, you can tell Tekton to fetch it directly.
tkn pipeline start my-pipeline --git-repo https://github.com/myuser/my-repo.git --git-branch main --git-subdir pipelines/my-app
Here, tkn (the Tekton CLI) is instructed to find my-pipeline within the pipelines/my-app directory of the main branch on GitHub. Tekton then processes this definition as if it were a local file.
This remote resolution capability is powered by Tekton’s PipelineResolver and TaskResolver resources. These custom resources act as intermediaries, translating a remote reference (like a Git URL or an artifact URI) into a Tekton Pipeline or Task object that the Tekton controller can understand and execute.
The core idea is to decouple the definition of your pipelines and tasks from their execution. This allows for a more flexible and distributed CI/CD architecture. You can version your pipeline definitions alongside your application code in Git, or you can package them as immutable artifacts in an OCI registry, treating them like any other containerized software component.
There are two primary mechanisms for remote resolution: Git and OCI Bundles.
Git Resolution:
When you specify a Git repository, Tekton clones the repository (or a specified subdirectory) and looks for a pipeline.yaml or task.yaml file. The tkn command-line tool automates this by passing Git-specific flags. Under the hood, Tekton uses a PipelineResolver or TaskResolver that’s configured to point to your Git repository. This resolver will periodically check the repository for updates if configured, or fetch on demand.
OCI Bundle Resolution:
OCI bundles are a more structured way to distribute Tekton resources. A bundle is essentially an OCI image that contains your Tekton Pipeline or Task definitions, along with any associated Task definitions they might depend on. You can push these bundles to any OCI-compliant registry (like Docker Hub, Quay.io, or your own private registry).
To use an OCI bundle, you’d typically reference it using a URI:
tkn pipeline start my-pipeline --bundle oci://myregistry.com/myorg/my-pipeline-bundle:v1.0.0
Tekton then pulls this bundle, extracts the Tekton resources from it, and uses them to create and run the pipeline. This is particularly useful for sharing and versioning pipeline definitions across different teams or environments.
The actual mechanism involves Tekton controllers watching for PipelineResolver and TaskResolver resources. When a resolver is created, it specifies the remote location and a ref (like a Git branch/tag or an OCI image digest/tag). The Tekton controller then uses a specific "resolver" component (e.g., git-resolver, bundle-resolver) to fetch the content from the remote. If the content is a Tekton resource definition (YAML), it’s converted into a Pipeline or Task object. If it’s an OCI bundle, the controller extracts the Tekton resources within the bundle.
The Pipeline or Task object itself is then created or updated in the Kubernetes cluster, making it available for execution. This means that when you run tkn pipeline start my-pipeline, the tkn CLI is essentially creating a PipelineRun that references a Pipeline which was dynamically fetched and registered via a PipelineResolver.
A common point of confusion is how Tekton ensures it’s using the correct version of a pipeline definition from Git. While you can specify a branch or tag, if you want strict immutability, you should use OCI bundles with specific image digests. This guarantees that the exact artifact you built and tested is the one being deployed, preventing unexpected changes if the Git branch is updated.
The next step in mastering Tekton’s remote capabilities is understanding how to secure these remote fetches, especially when dealing with private Git repositories or registries.