Tekton vs. GitHub Actions

Das Gespräch kommt immer wieder in ähnlicher Form: “Wir wollen unsere Pipelines zu Tekton migrieren.” Manchmal folgt kurz darauf die umgekehrte Begegnung: “Wir hatten Tekton und wechseln jetzt zu GitHub Actions.”

Beide Richtungen passieren. Das sagt etwas.

Was Kubernetes-nativ konkret bedeutet

Tekton modelliert CI als Kubernetes-Objekte: ein Task ist eine Folge von Steps (Container im selben Pod), eine Pipeline verkettet Tasks, ein PipelineRun ist die konkrete Ausführung. Daten zwischen Tasks fließen über Workspaces — typischerweise PersistentVolumeClaims, die du explizit definierst.

Das gibt dir die gesamte Kubernetes-Toolchain geschenkt: RBAC regelt, wer Pipelines starten darf. Jeder Task kann mit einem eigenen ServiceAccount laufen — der Build-Step bekommt Registry-Push-Rechte, der Test-Step nicht. ResourceQuotas begrenzen, was ein Team an Build-Kapazität verbrauchen kann. Alles liegt als YAML im Git-Repo und lässt sich per GitOps deployen wie jede andere Workload.

Der Preis ist Verbosity, und sie ist real. Ein “checkout, build, test, push” braucht in GitHub Actions etwa fünfzehn Zeilen. In Tekton definierst du Tasks, eine Pipeline, Workspace-Bindings und einen Trigger — schnell 150+ Zeilen über mehrere Dateien. Dazu kommt: Tekton hat keinen eingebauten Webhook-Empfang. Für “Pipeline läuft bei jedem Push” brauchst du Tekton Triggers mit EventListener, TriggerBinding und TriggerTemplate — drei weitere Ressourcen-Typen, bevor der erste Build automatisch startet. Das Ökosystem vorgefertigter Tasks (Tekton Hub) ist klein gegen den GitHub Actions Marketplace mit seinen tausenden Actions.

Die GitHub-Actions-Seite, ehrlich betrachtet

GitHub Actions ist developer-friendly, und das ist keine Floskel: Push, PR, Schedule, Issue-Events out-of-the-box, kompaktes YAML, Logs direkt im PR. Für ein Team, das Code testen und deployen will, ist die Time-to-Working-Pipeline um Größenordnungen kürzer. Mit OIDC-Federation entfallen sogar langlebige Cloud-Credentials — wie das mit AWS konkret funktioniert, haben wir separat beschrieben.

Die Einschränkungen: GitHub-hosted Runner sind Standard-VMs — wer spezielle Hardware, große Caches oder Netzwerkzugriff ins interne Netz braucht, landet bei Self-Hosted Runnern. Und die sind ein eigenes Betriebsthema: der Actions Runner Controller (ARC) betreibt Runner als Pods auf Kubernetes, will aber gepatcht, skaliert und überwacht werden — ein Teil des “Managed Service”-Versprechens löst sich damit auf. Vendor-Lock-in ist ebenfalls real: Workflow-YAML, Marketplace-Actions und Event-Modell migrieren nicht zu GitLab CI oder Tekton; bei mehreren hundert Workflows ist das eine Migration von Monaten.

Kosten sind kein klares Argument für eine Seite. GitHub Actions kostet pro Minute (Self-Hosted Runner sind minutenkostenfrei, aber du zahlst die Infrastruktur und den Betrieb). Tekton kostet Cluster-Ressourcen plus — und das wird notorisch unterschätzt — Engineering-Zeit für Betrieb, Upgrades und den Bau der Standard-Tasks, die der Marketplace dir sonst schenkt.

Wann welches — und der Mittelweg

Tekton lohnt sich in spezifischen Situationen: wenn Compliance verlangt, dass Build-Traffic und Quellcode das eigene Netzwerk nicht verlassen. Wenn die Organisation Git-Provider-neutral bleiben will oder muss (Tekton funktioniert mit GitHub, GitLab und Bitbucket gleichermaßen). Wenn ein Platform-Team CI als Produkt baut — standardisierte, versionierte Pipeline-Bausteine, die Teams konsumieren, mit Kubernetes-RBAC und Quotas als Governance-Layer. In dem Szenario ist die Verbosity kein Bug: das Platform-Team schreibt die Tasks einmal, App-Teams referenzieren sie.

Ein Argument, das in Supply-Chain-sensiblen Umgebungen für Tekton spricht: Tekton Chains. Der Controller beobachtet abgeschlossene TaskRuns, signiert deren Ergebnisse und erzeugt SLSA-Provenance-Attestationen — die Build-Herkunft eines Images ist damit kryptografisch belegbar, direkt aus der CI-Infrastruktur heraus. GitHub Actions hat mit Artifact Attestations inzwischen ein Gegenstück, aber wer die gesamte Beweiskette unter eigener Kontrolle braucht, landet wieder beim Cluster-nativen Ansatz. Wie Provenance und Signaturen zusammenspielen, steht im Artikel zu Cosign und SLSA.

Für die meisten Teams ohne diese Anforderungen: GitHub Actions, fast immer. Der Produktivitätsgewinn ist real und summiert sich täglich.

Ein pragmatischer Mittelweg existiert: GitHub Actions als Frontend für Standard-CI (Tests, Linting, PR-Checks), Tekton für die Build-Workloads, die volle Cluster-Integration brauchen — etwa Image-Builds mit Kaniko im internen Netz mit direktem Zugriff auf die private Registry. Das ist mehr Komplexität, zwei Systeme statt einem. Manchmal ist es die richtige Komplexität — aber sie will im Interview wie in der Praxis begründet sein, nicht behauptet.

Im Interview ist die Frage übrigens selten “kennst du Tekton?”, sondern ein verkleideter Trade-off-Test: Managed Convenience gegen Kontrolle und Souveränität. Wer beide Migrationsrichtungen aus dem ersten Absatz erklären kann, hat die Frage verstanden. Mehr zu CI-Architekturen im Lernpfad CI/CD und Builds.