Tekton#

The Tekton provider runs only in Kubernetes. Tack receives Tangled pipeline triggers, creates a Tekton PipelineRun for an existing in-cluster Pipeline, watches that PipelineRun, and publishes sh.tangled.pipeline.status records back to Tangled.

Tekton Triggers are intentionally not used. Tack already performs the event-to-run translation, and Tekton's native execution object is the PipelineRun.

IMPORTANT

This is a community-contributed provider. I (mitchellh) haven't verified its functionality beyond what others have said worked. I've only reviewed the code for obvious issues and to ensure it doesn't do anything to jeopardize the rest of Tack.

Required cluster setup#

Tekton Pipelines is installed in the cluster.
Tack is deployed inside the same cluster.
The target Tekton Pipeline objects already exist in the namespace tack is configured to use.
Tack's Kubernetes service account has RBAC to:
- create, get, list, and watch tekton.dev pipelineruns
- get, list, and watch tekton.dev taskruns
- get and list pods
- get pod logs via pods/log

Example RBAC:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: tack-tekton
  namespace: ci
rules:
  - apiGroups: ["tekton.dev"]
    resources: ["pipelineruns"]
    verbs: ["create", "get", "list", "watch"]
  - apiGroups: ["tekton.dev"]
    resources: ["taskruns"]
    verbs: ["get", "list", "watch"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list"]
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get"]

Configure Tack#

Env var	Description
`TACK_TEKTON_ENABLED`	Set to `1` to enable the Tekton provider
`TACK_TEKTON_NAMESPACE`	Namespace for created `PipelineRun`s (default `default`)

The provider uses Kubernetes in-cluster service account credentials. It will not run from a local kubeconfig.

Naming#

There are three separate names:

Tack workflow name: the Tangled workflow filename/name, e.g. ci.yml. This remains the Tangled-facing workflow identity in status records.
Tekton Pipeline name: the existing in-cluster pipeline definition, e.g. repo-ci. This is written to spec.pipelineRef.name.
Tekton PipelineRun name: generated by tack per trigger/workflow, e.g. tack-ci-yml-<short-hash>. This is the concrete execution object tack watches and stores.

Workflow YAML#

Only the provider and target pipeline are required:

tack:
  tekton:
    pipeline: repo-ci

Optional fields:

tack:
  tekton:
    pipeline: repo-ci
    service_account: pipeline-runner
    params:
      image: example/app

params are forwarded as string Tekton params. Tack also stores the knot, pipeline rkey, workflow name, actor DID, commit, and branch as PipelineRun annotations, so operators can inspect the Kubernetes object and connect it back to the Tangled trigger.

Example Pipeline#

apiVersion: tekton.dev/v1
kind: Pipeline
metadata:
  name: repo-ci
  namespace: ci
spec:
  params:
    - name: image
      type: string
  tasks:
    - name: test
      taskSpec:
        params:
          - name: image
            type: string
        steps:
          - name: test
            image: golang:1.25
            script: |
              set -eu
              echo "building $(params.image)"
              go test ./...
        workspaces: []
      params:
        - name: image
          value: $(params.image)

Detailed CI behavior belongs in the in-cluster Pipeline. The Tangled workflow YAML should stay small: select tekton, pick the target pipeline, and pass only the small set of params that pipeline expects.

Configure Feed