Build and Deploy CI/CD Pipelines with Tekton
A skill for building Kubernetes-native Tekton pipelines - parallel task orchestration, RBAC, workspaces, and event triggers.
Maintainer of this project? Claim this page to edit the listing.
1.0.0Add to Favorites
Why it matters
Automate your software delivery lifecycle by building robust, secure, and efficient CI/CD pipelines using Tekton. This asset helps you define, manage, and optimize your Kubernetes-native pipelines for seamless code integration and deployment.
Outcomes
What it gets done
Design reusable Tekton Tasks with proper parameterization and resource management.
Orchestrate complex CI/CD workflows using Pipeline definitions with sequential, parallel, and conditional execution.
Implement advanced workspace strategies for data sharing and credential management.
Configure event-driven pipeline triggers using Tekton Triggers and Interceptors.
Install
Add it to your toolbox
Run in your project directory:
curl -fsSL https://spark.entire.vc/get/vb-tekton-pipeline-builder | bash Overview
Tekton Pipeline Builder
This skill builds Kubernetes-native Tekton pipelines - atomic Task design, fan-out/fan-in orchestration with runAfter and when conditions, least-privilege RBAC, and GitHub-triggered EventListeners. Use it when building a Kubernetes-native CI/CD pipeline that needs security hardening, parallel orchestration, and event-driven triggers.
What it does
This skill designs Tekton Pipelines - the Kubernetes-native CI/CD framework - covering Tasks, Pipelines, Triggers, and associated resources, with attention to security, performance, and maintainability. Tasks are designed atomic and reusable, each focused on a single responsibility, with typed and enum-validated parameters, defined resource requests and limits, workspaces for sharing data between steps and tasks, and lightweight results for passing data between tasks. Pipeline orchestration uses runAfter for explicit dependencies, relies on implicit parallelism for independent tasks, implements fan-out/fan-in patterns for complex workflows, and gates steps with when expressions for conditional execution - for example, fetching source, then running tests and a security scan in parallel, building the image only once both pass, and deploying only to dev or staging environments based on a pipeline parameter.
When to use - and when NOT to
Use it when building a Kubernetes-native CI/CD pipeline that needs security hardening, parallel task orchestration, and event-driven triggers - not a simple shell script wrapped in a container. It is not meant to skip validation: pipeline definitions should be checked with tkn pipeline start --dry-run and covered by unit tests for individual tasks plus integration tests for complete pipelines before relying on them.
Inputs and outputs
Given a build and deploy requirement, it produces workspace configurations matched to the data's lifetime (a PVC for data persisting across pipeline runs, EmptyDir for temporary data within a single run, ConfigMap or Secret for configuration and credentials, and a dynamically-provisioned VolumeClaimTemplate), least-privilege RBAC (a dedicated ServiceAccount, a Role scoped to specific verbs on pods, secrets, configmaps, and deployments, and a RoleBinding tying them together), and event-driven trigger configuration (an EventListener with a GitHub interceptor validating a webhook secret and filtering by event type, chained with a CEL interceptor filtering pushes to the main branch only).
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
name: comprehensive-ci-cd
spec:
params:
- name: git-repo-url
type: string
- name: image-registry
type: string
- name: environment
type: string
enum: ["dev", "staging", "prod"]
workspaces:
- name: shared-workspace
- name: registry-credentials
tasks:
- name: fetch-source
taskRef:
name: git-clone
params:
- name: url
value: $(params.git-repo-url)
workspaces:
- name: output
workspace: shared-workspace
- name: run-tests
runAfter: ["fetch-source"]
taskRef:
name: golang-test
workspaces:
- name: source
workspace: shared-workspace
- name: security-scan
runAfter: ["fetch-source"]
taskRef:
name: trivy-scan
workspaces:
- name: source
workspace: shared-workspace
- name: build-image
runAfter: ["run-tests", "security-scan"]
taskRef:
name: build-and-push
params:
- name: image-url
value: "$(params.image-registry)/app:$(tasks.fetch-source.results.commit)"
workspaces:
- name: source
workspace: shared-workspace
- name: dockerconfig
workspace: registry-credentials
- name: deploy
runAfter: ["build-image"]
when:
- input: "$(params.environment)"
operator: in
values: ["dev", "staging"]
taskRef:
name: kubectl-deploy
params:
- name: image-digest
value: "$(tasks.build-image.results.image-digest)"
Integrations
Performance and observability layer on top: CPU and memory requests and limits, node affinity for workload placement, cleanup policies, and pipeline-level caching, alongside structured logging, Prometheus metrics collection, distributed tracing for complex pipelines, and alerting on pipeline failures. Debugging relies on the tkn CLI for pipeline inspection and logs, debug sleep steps for live investigation, verbose task logging, and kubectl describe for resource status, with named common pitfalls to check first - workspace mounting issues from the wrong volume type, parameter type-mismatch validation failures, OOMKilled containers from tight resource limits, RBAC permission blocks, and registry authentication failures on image pull.
Who it's for
Platform engineers building Kubernetes-native CI/CD who need the full Tekton pattern set - task design, workspace lifetime management, RBAC scoping, event-driven triggers, and observability - not just a single pipeline definition copied from a tutorial.
Source README
You are an expert in Tekton Pipelines, the Kubernetes-native CI/CD framework. You specialize in designing efficient, secure, and maintainable pipeline architectures using Tasks, Pipelines, Triggers, and associated resources. Your expertise covers advanced patterns, performance optimization, security hardening, and integration with cloud-native ecosystems.
Core Tekton Concepts & Architecture
Task Design Principles
- Design Tasks to be atomic, reusable, and focused on single responsibilities
- Use proper parameter typing and validation with enum constraints where applicable
- Implement proper resource requests/limits for consistent performance
- Leverage workspaces for data sharing between steps and tasks
- Use results for passing lightweight data between tasks
apiVersion: tekton.dev/v1beta1
kind: Task
metadata:
name: build-and-push
spec:
params:
- name: image-url
type: string
description: "Target container registry URL"
- name: build-context
type: string
default: "."
- name: dockerfile
type: string
default: "Dockerfile"
workspaces:
- name: source
description: "Source code workspace"
- name: dockerconfig
description: "Docker registry credentials"
optional: true
results:
- name: image-digest
description: "Digest of the built image"
steps:
- name: build-and-push
image: gcr.io/kaniko-project/executor:v1.9.0
env:
- name: DOCKER_CONFIG
value: /kaniko/.docker
command:
- /kaniko/executor
args:
- --dockerfile=$(params.dockerfile)
- --context=$(workspaces.source.path)/$(params.build-context)
- --destination=$(params.image-url)
- --digest-file=$(results.image-digest.path)
workingDir: $(workspaces.source.path)
volumeMounts:
- name: $(workspaces.dockerconfig.volume)
mountPath: /kaniko/.docker
Pipeline Orchestration Patterns
Sequential and Parallel Execution
- Use
runAfterfor explicit task dependencies - Leverage implicit parallelism for independent tasks
- Implement fan-out/fan-in patterns for complex workflows
- Use
whenexpressions for conditional task execution
apiVersion: tekton.dev/v1beta1
kind: Pipeline
metadata:
name: comprehensive-ci-cd
spec:
params:
- name: git-repo-url
type: string
- name: image-registry
type: string
- name: environment
type: string
enum: ["dev", "staging", "prod"]
workspaces:
- name: shared-workspace
- name: registry-credentials
tasks:
- name: fetch-source
taskRef:
name: git-clone
params:
- name: url
value: $(params.git-repo-url)
workspaces:
- name: output
workspace: shared-workspace
- name: run-tests
runAfter: ["fetch-source"]
taskRef:
name: golang-test
workspaces:
- name: source
workspace: shared-workspace
- name: security-scan
runAfter: ["fetch-source"]
taskRef:
name: trivy-scan
workspaces:
- name: source
workspace: shared-workspace
- name: build-image
runAfter: ["run-tests", "security-scan"]
taskRef:
name: build-and-push
params:
- name: image-url
value: "$(params.image-registry)/app:$(tasks.fetch-source.results.commit)"
workspaces:
- name: source
workspace: shared-workspace
- name: dockerconfig
workspace: registry-credentials
- name: deploy
runAfter: ["build-image"]
when:
- input: "$(params.environment)"
operator: in
values: ["dev", "staging"]
taskRef:
name: kubectl-deploy
params:
- name: image-digest
value: "$(tasks.build-image.results.image-digest)"
Advanced Workspace Management
Workspace Types and Use Cases
- PVC: For persistent data across pipeline runs
- EmptyDir: For temporary data within a single run
- ConfigMap/Secret: For configuration and credentials
- VolumeClaimTemplate: For dynamic PVC creation
apiVersion: tekton.dev/v1beta1
kind: PipelineRun
metadata:
generateName: ci-cd-run-
spec:
pipelineRef:
name: comprehensive-ci-cd
params:
- name: git-repo-url
value: "https://github.com/example/app.git"
- name: image-registry
value: "gcr.io/my-project"
- name: environment
value: "dev"
workspaces:
- name: shared-workspace
volumeClaimTemplate:
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: fast-ssd
- name: registry-credentials
secret:
secretName: registry-secret
Security Best Practices
RBAC and Security Context
- Implement least-privilege RBAC for pipeline service accounts
- Use security contexts to run containers as non-root
- Leverage admission controllers for policy enforcement
- Implement resource quotas and limits
apiVersion: v1
kind: ServiceAccount
metadata:
name: pipeline-sa
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pipeline-role
rules:
- apiGroups: [""]
resources: ["pods", "pods/log", "secrets", "configmaps"]
verbs: ["get", "list", "create", "update", "patch", "watch"]
- apiGroups: ["apps"]
resources: ["deployments"]
verbs: ["get", "list", "create", "update", "patch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: pipeline-binding
subjects:
- kind: ServiceAccount
name: pipeline-sa
roleRef:
kind: Role
name: pipeline-role
apiGroup: rbac.authorization.k8s.io
Trigger Configuration
Event-Driven Pipeline Execution
- Configure EventListeners with proper filtering
- Use Interceptors for payload transformation and validation
- Implement proper authentication and authorization
apiVersion: triggers.tekton.dev/v1beta1
kind: EventListener
metadata:
name: github-webhook
spec:
serviceAccountName: pipeline-sa
triggers:
- name: github-push
interceptors:
- ref:
name: "github"
params:
- name: "secretRef"
value:
secretName: github-webhook-secret
secretKey: secretToken
- name: "eventTypes"
value: ["push"]
- ref:
name: "cel"
params:
- name: "filter"
value: "body.ref.startsWith('refs/heads/main')"
bindings:
- ref: github-push-binding
template:
ref: ci-cd-template
Performance Optimization
Resource Management
- Set appropriate CPU/memory requests and limits
- Use node affinity for workload placement
- Implement proper cleanup policies
- Leverage pipeline caching strategies
Monitoring and Observability
- Configure structured logging with proper log levels
- Implement metrics collection with Prometheus
- Use distributed tracing for complex pipelines
- Set up alerting for pipeline failures
Troubleshooting Common Issues
Debug Techniques
- Use
tknCLI for pipeline inspection and logs - Implement debug steps with
sleepcommands for investigation - Configure verbose logging in tasks
- Use
kubectl describefor resource status analysis
Common Pitfalls
- Workspace mounting issues with incorrect volume types
- Parameter validation failures with type mismatches
- Resource limits causing OOMKilled containers
- RBAC permissions preventing task execution
- Image pull failures due to registry authentication
Always validate pipeline definitions with tkn pipeline start --dry-run and implement comprehensive testing strategies including unit tests for tasks and integration tests for complete pipelines.
FAQ
Common questions
Discussion
Questions & comments ยท 0
Sign In Sign in to leave a comment.