Tekton’s git-clone task doesn’t actually clone your repository; it fetches specific revisions into a pre-existing workspace.
Here’s a git-clone task in action, checking out a specific commit from a GitHub repository into a workspace named source-ws:
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: git-clone-example
spec:
params:
- name: url
description: The URL of the git repository.
type: string
default: https://github.com/tektoncd/pipeline.git
- name: revision
description: The git revision (branch, tag, or commit hash) to checkout.
type: string
default: main
- name: sslVerify
description: Whether to verify the SSL certificate.
type: string
default: "true"
workspaces:
- name: source-ws
description: Workspace to clone the repository into.
steps:
- name: clone
image: gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/git-clone:v0.36.1 # Use a specific, stable image
script: |
git clone $(params.url) .
git checkout $(params.revision)
workingDir: $(workspaces.source-ws.path)
securityContext:
privileged: "true" # Required for git operations within the container
This task is designed to be a foundational step in many Tekton pipelines. Its primary purpose is to reliably retrieve source code from a Git repository into a shared workspace that subsequent tasks can then use for building, testing, or deploying. It abstracts away the complexities of Git commands, providing a declarative way to manage code versions within your CI/CD workflows.
Let’s dive into how it works internally. The git-clone task utilizes a specialized container image (gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/git-clone). This image isn’t just a generic git client; it’s optimized for Tekton’s workspace model. When the task runs, it mounts the specified workspace (source-ws in the example) at the path defined by $(workspaces.source-ws.path). The script section then executes standard Git commands (git clone and git checkout) within this mounted directory. The workingDir parameter ensures these commands operate directly within the workspace. The sslVerify parameter allows you to control whether Git performs SSL certificate validation when connecting to the remote repository, which can be useful in environments with self-signed certificates.
The params section is where you define the specifics of the repository you want to fetch.
url: The absolute URL to your Git repository. This can be an HTTPS or SSH URL.revision: This is crucial for version control. You can specify a branch name (likemainordevelop), a tag (likev1.0.0), or a specific commit hash (e.g.,a1b2c3d4e5f6...). Tekton will then ensure that the workspace contains the exact state of the repository at that revision.sslVerify: A boolean string ("true"or"false") to enable or disable SSL verification.
The workspaces section declares the source-ws workspace. Tekton will provision this workspace (often backed by PersistentVolumes or ephemeral storage) and make its path available to the git-clone task. Any subsequent tasks in the pipeline that declare a dependency on source-ws will have access to the code that was checked out.
The securityContext.privileged: "true" is often necessary because Git operations, especially those involving network access and file system manipulation within a container, might require elevated privileges. This ensures the container has the necessary permissions to perform the clone and checkout operations effectively.
A subtle but important detail: the git-clone task doesn’t automatically delete previous contents of the workspace. If you’re running this task multiple times against the same workspace and expect a clean slate, you might need to add a preliminary step to clear the workspace directory.
The most common next step after cloning your source code is to build it, which often involves a buildah or docker task that will read from the source-ws workspace.