Tekton’s Git and Bundle Resolvers don’t actually fetch remote resources themselves; they rely on a container image registry to do the heavy lifting of fetching and storing remote code.
Let’s see this in action. Imagine you have a Tekton PipelineRun that references a Task defined in a remote Git repository.
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
name: git-remote-example
spec:
pipelineSpec:
tasks:
- name: fetch-and-build
taskSpec:
params:
- name: git-url
type: string
description: The URL of the Git repository
steps:
- name: clone-repo
image: alpine/git
script: |
#!/bin/sh
echo "Cloning repository from: $(params.git-url)"
git clone $(params.git-url) /workspace/repo
ls -l /workspace/repo
When this PipelineRun executes, Tekton doesn’t directly clone the Git URL. Instead, it looks for a Task definition. If that Task is specified as a remote resource (e.g., apiVersion: tekton.dev/v1beta1 kind: Task metadata: name: my-remote-task ref: bundle: gcr.io/my-project/my-bundle:latest), Tekton’s bundle resolver kicks in. This resolver’s job is to find that bundle in a container image registry. It tells the Kubernetes kubelet (running on the node where the pod will be scheduled) to pull the image gcr.io/my-project/my-bundle:latest. The kubelet then uses the container runtime (like Docker or containerd) to fetch the image layers from the registry. The Task definition, along with any associated Pipeline definitions, is essentially embedded within this container image.
The Git resolver works similarly, but instead of a container image, it expects the Git repository to be referenced. When a Task or Pipeline is defined with a ref.git field pointing to a Git repository URL, Tekton doesn’t clone it directly. It delegates this to the PipelineRun’s spec.resources section, where you’d typically define a PipelineResource of type git. This PipelineResource is what’s actually responsible for interacting with Git. The Tekton controller, upon seeing this PipelineResource configuration, will instruct the kubelet to pull a specific image that contains the necessary tooling (like alpine/git in our example) and mount the repository into the pod. The actual cloning command within the step will then execute using this tooling.
The problem this solves is managing and distributing Tekton configurations across different environments. Instead of manually applying YAML files everywhere, you can package your Tasks and Pipelines into container images (bundles) or point to Git repositories. This leverages existing infrastructure for code distribution and versioning. The bundle resolver uses the OCI (Open Container Initiative) standard, allowing Tekton to fetch configurations from any OCI-compliant registry (Docker Hub, GCR, ECR, etc.). The git resolver, on the other hand, relies on standard Git protocols.
The mental model to build is that Tekton itself doesn’t contain the logic for fetching external resources like Git repos or container images. It’s an orchestrator that configures pods to perform these actions. The actual fetching is done by the container runtime managed by kubelet for bundles, and by tooling defined within the task’s steps (often a Git client) for Git repositories, triggered by PipelineResource definitions.
When you use a bundle reference, the image: field in your Task or Pipeline definition isn’t just for the runtime of your build steps; it’s also the source of the Tekton definition itself. The Tekton controller queries the registry for this image, extracts the Tekton manifests from it, and then uses those manifests to create the Task or Pipeline objects within the Kubernetes cluster. This means your Task definition is versioned and distributed just like any other containerized application.
The most surprising thing is that the image field in a Task definition, when used with a bundle reference, doesn’t just specify the image for your build steps; it is the Tekton definition itself, packaged and ready to be pulled from a registry.
The next step is understanding how to build and push these Tekton bundles to a container registry.