Tekton Catalog

repository·main·Indexed 20 days ago

https://github.com/tektoncd/catalog

A centralized collection of reusable Tekton Task, Pipeline, and StepAction resources. It provides Kubernetes manifests for CI/CD pipelines, including specialized pipelines such as build-push-gke-deploy, Buildpacks for OCI image transformation, and an OpenWhisk application pipeline for Knative Serving.

Tokens
232.7K
Snippets
654
Records
1.1K
Agent score
71%

What's inside Tekton Catalog

  1. Overview of the OpenWhisk application pipeline for Knative

    main

    This Tekton Catalog offering provides a single pipeline designed to build containers compatible with either Apache OpenWhisk or Knative Serving.

    It is specifically intended for supported runtimes (such as NodeJS, Python, and Java) that use a proxy to enforce a documented contract for function initialization (function injection) and execution. The resulting containers can be run on Knative Serving without requiring an OpenWhisk control plane, or on OpenWhisk's Kubernetes clusters.

  2. Overview of Valint

    main

    Valint is a tool for managing the generation, storage, and validation of supply chain evidence. It supports two primary types of evidence:

    1. CycloneDX SBOMs: Software Bill of Materials.
    2. SLSA Provenance: Supply-chain Levels for Software Artifacts.

    Valint enables cryptographic signing of generated evidence, allowing for later verification of artifacts against their origin and signer identity. It can also capture any 3rd party report, scan, or configuration file as evidence.

  3. Use the Prometheus Gate Task to monitor SLOs

    main

    The prometheus-gate Task acts as a gatekeeper that queries a Prometheus API in a loop. It waits for a specific Service Level Objective (SLO) to be met over a defined time period. If the query returns an empty dataset, the task treats it as a failure and retries.

    Supported strategies for validating the range query results include:

    • min: Enforces that all values in the time period meet a minimum value.
    • max: Enforces that no value in the time period exceeds the target.
    • equals: Enforces that the target value is maintained for the entire time period.

    Note: p95 and p99 strategies are planned but not currently supported.

  4. Publish Tekton Catalog resources as Bundles

    main

    The tekton-catalog-publish StepAction automates the process of publishing individual Tasks or StepActions from a Tekton Catalog into Tekton Bundles.

    Bundles are pushed to an OCI registry using the following pattern:

    • Primary: $REGISTRY/$PATH/<task/stepaction-name>:<task/stepaction-version>
    • With optional tag: $REGISTRY/$PATH/<task/stepaction-name>:$TAG

    The task uses the tkn bundle command. Note that support for decoding StepActions requires tkn version v0.34.0 or later.

    By default, the task applies two OCI labels to the published bundles:

    • org.opencontainers.image.description: The resource name (derived from the containing folder name).
    • org.opencontainers.image.version: The resource version (derived from the containing folder name and the TAG parameter, if provided).
  5. Use the Helm Render Manifests From Repo Task

    main

    The helm-render-manifests-from-repo Task implements the GitOps Rendered Manifests Pattern. It templates a Helm chart from a remote repository and outputs the resulting YAML manifest to a specified workspace volume.

    By default, the task runs with --validate enabled, which allows the template command to populate Helm builtins (like Capabilities) from a target server. If this behavior is not desired, you can override the extra_args parameter.

    # Example TaskRun to render a Prometheus chart
    apiVersion: tekton.dev/v1
    kind: TaskRun
    metadata:
      name: example-helm-render-manifests-from-repo
    spec:
      taskRef:
        name: helm-render-manifests-from-repo
      params:
      - name: helm_repo
        value: https://prometheus-community.github.io/helm-charts
      - name: chart_name
        value: prometheus-community/prometheus
      - name: release_version
        value: 25.21.0
      - name: release_name
        value: helm-repo-sample
      - name: extra_args
        value: '--skip-tests'
      - name: overwrite_values
        value: alertmanager.enabled=false,kube-state-metrics.enabled=false,prometheus-node-exporter.enabled=false,prometheus-pushgateway.enabled=false
  6. Configure the trivy-scanner Task

    main

    The trivy-scanner Task allows you to integrate the Trivy vulnerability scanner into Tekton Pipelines to scan container images, file systems, Git repositories, and Infrastructure as Code (IaC) files.

    To use this task, you must provide the ARGS and IMAGE_PATH parameters. You can optionally specify a custom Trivy container image or enable air-gapped mode.

  7. Use the BentoML Task to manage BentoML services

    main
    The BentoML Task enables operations on BentoML services via the BentoML CLI. It is particularly useful for integrating BentoML's artifact bundle retrieval into CI/CD pipelines, allowing models to be packaged into containers automatically. This task can be used to retrieve full ML build environments directly into a workspace.
  8. Use Workspaces and Resources with Jib Maven Task

    main

    The jib-maven Task requires a workspace for source code and uses a PipelineResource to manage the output image.

    Workspaces

    • source: A workspace containing the source code to be built.

    Resources

    • image (Output): A PipelineResource of type image that specifies the destination Docker image name.
  9. Configure the `pr` workspace structure

    main

    The pr workspace is used to represent the state of a Pull Request. The Task uses specific file paths within this workspace to manage different PR attributes:

    • /labels/<label>: Empty files where the filename is the label name (non-URL safe characters must be URL encoded).
    • /status/<status>: JSON files representing PR statuses.
    • /comments/<comment>: JSON files (in download mode) or plain text files (in upload mode) representing comments.
    • base.json: Information about the base commit.
    • head.json: Information about the head commit.
    • pr.json: General information about the PR.
    • .MANIFEST: A file populated during download mode used to track the current state for comparison during upload mode.
  10. Use the openshift-client-python library in Python scripts

    main

    The Task provides a Python environment where you can import the openshift module (aliased as oc) to interact with your cluster.

    Core Concepts

    Context and Timeouts

    Use oc.project('name') to set the project context for all subsequent oc commands and oc.timeout(seconds) to limit execution time.

    Selecting Resources

    Use oc.selector('resource_type') to query resources.

    • .qnames(): Returns a list of qualified names (e.g., ['pod/xyz', 'pod/abc']).
    • .objects(): Returns an iterator of APIObject instances representing the current state of the resources.

    Interacting with APIObjects

    An APIObject provides convenience methods for resource interaction:

    • .name(): Returns the resource name.
    • .print_logs(...): Prints logs with specified arguments like timestamps or tail.
    • .model: Returns a Model instance representing the underlying resource definition.

    Model objects allow for safe, deep navigation of resource attributes using dot notation. If a field does not exist, it returns the oc.Missing singleton instead of raising an error. This allows you to avoid boilerplate existence checks.

    Note: When checking for existence, compare against the oc.Missing singleton (e.g., if field is not oc.Missing:).

    import openshift as oc
    
    # Set context and timeout
    with oc.project('my-project'), oc.timeout(600):
        # Select pods and iterate over them
        for pod_obj in oc.selector('pods').objects():
            print(f"Analyzing {pod_obj.name()}")
            
            # Access the underlying model for deep navigation
            pod_model = pod_obj.model
            
            # Safe dot-notation navigation
            for owner in pod_model.metadata.ownerReferences:
                if owner.kind is not oc.Missing:
                    print(f"Owned by: {owner.kind}")
  11. Configure git-clone Workspaces

    main

    The git-clone Task supports several optional workspaces for authentication and configuration:

    • output (Required): The destination workspace for the cloned repository.
    • ssh-directory (Optional): Provides SSH credentials. Should include a private key (e.g., id_rsa) and optionally config and known_hosts. It is strongly recommended to bind this to a Kubernetes Secret.
    • ssl-ca-directory (Optional): Provides custom CA certificates (e.g., ca-bundle.crt) for interacting with git remotes using custom CAs.
    • basic-auth (Optional): Contains .gitconfig and .git-credentials files for username/password or token-based authentication. It is strongly recommended to bind this to a Kubernetes Secret.