Skip to content

Instantly share code, notes, and snippets.

@afrittoli

afrittoli/tekton-cncf.md

Last active May 1, 2024 08:55
Show Gist options
  • Save afrittoli/014e5bebdb29b7775c26a583bdaf0ac8 to your computer and use it in GitHub Desktop.
Save afrittoli/014e5bebdb29b7775c26a583bdaf0ac8 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
tekton-cncf.md

Tekton Incubation Application

v1.5 This template provides the project with a framework to inform the TOC of their conformance to the Incubation Level Criteria.

Project Repo(s): https://github.com/tektoncd/ Project Site: https://tekton.dev Sub-Projects: pipeline, triggers, cli, dashboard, operator, chains, catalog Communication: https://github.com/tektoncd/community/blob/main/contact.md#slack

Project points of contacts: Dibyo Mukherjee, Andrea Frittoli, Vincent Demeester, Jerop Kipruto, Chitrang Patel, Governing Board members

Incubation Criteria Summary for Tekton

Tekton is a powerful and flexible open-source framework for creating CI/CD systems, allowing developers to build, test, and deploy across cloud providers and on-premise systems.

Tekton provides building blocks for cloud-native CI/CD, allowing CI/CD pipelines to benefit from the scalability benefits of the cloud. Tekton based CI/CD workflows can benefit from the rich ecosystem of cloud-native tools for developing, managing, observing and securing cloud-native applications, applied to CI/CD workflows.

The Tekton project has graduated from the Continuous Delivery Foundation and it now would like to apply for incubation at the CNCF because of its affinity with the cloud-native ecosystem and its existing ties to various CNCF projects. Several Tekton adopters combine the project with other CNCF tools hosted under the CNCF TAG App Delivery. Having Tekton hosted under the same TAG would boost collaboration and ultimately benefit adopters, end-users and vendors alike.

Adoption Assertion

The project has been adopted by the following organizations in a testing and integration or production capacity:

  • Google
  • IBM
  • RedHat
  • Cloudbees
  • Nubank
  • Marriott Vacations Worldwide
  • OneStock
  • Open source projects that have adopted Tekton. See the adopters list and Tekton friends for lists
  • Other adopters include

Application Process Principles

Suggested

N/A

Required

  • Give a presentation and engage with the domain specific TAG(s) to increase awareness
    • This was completed and occurred on DD-MMM-YYYY, and can be discovered at $LINK.

Scheduled for 15.05.2024, Draft slides: here

  • TAG provides insight/recommendation of the project in the context of the landscape

  • All project metadata and resources are vendor-neutral.

  • Tekton source code is licensed under the Apache 2.0 license

  • Tekton is currently hosted by the Continuous Delivery Foundation, a Linux Foundation Project, which provides a vendor neutral home for the project brand and resources

  • Tekton governance is open and it ensures vendor neutrality through the maximum representation policy

  • Tekton design decisions happen in the open through the TEP proposal process, which ensures vendor neutrality by requiring approvals from two different companies

  • Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.

  • Met during Project's application on DD-MMM-YYYY.

  • Due Diligence Review.

Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.

Governance and Maintainers

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

  • Clear and discoverable project governance documentation.

  • Governance docs are available at github.com/tektoncd/community/blob/main/governance.md, linked from the community repo README

  • The community docs have a list of links to common community related information

  • Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.

    Since its inception, we have started a contributor ladder, came up with a proposals process (TEPs), and have made updates to governance to ensure vendor neutrality.

  • Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.

    All governance and related docs are in tektoncd/community. There is a bi-weekly community/governance meeting that is open to everyone.

  • Governance clearly documents vendor-neutrality of project direction.

    Tekton has contributions from multiple companies and vendors. The project has its own website, blog, Twitter, and slack accounts. It is currently part of the Continuous Delivery Foundation and as such its CI and other infrastructure is hosted by the CDF. The Tekton governance board has a maximum representation rule that ensures no one company can hold more than 40% of the seats at any given time. Changes to the project are managed through Tekton Enhancement Proposals (TEPs). The TEP workflow ensures that at least 2 maintainers from different companies have to approve a proposal before it is implemented.

  • Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.

    Decisions on leadership and changes to governance roles is documented at github.com/tektoncd/community/blob/main/governance.md#governance-meetings-and-decision-making-process. Contribution acceptance is documented in the process docs.

  • Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).

    Community members may play different roles as described in the contributor ladder. The ladder also describes promotions, demotions and removals, whether voluntary or by inactivity. There is a Tekton Vulnerability Management (VMT) Team to handle security incidents and reports besides various working groups.

  • Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).

    This is detailed in our contributor ladder docs.

  • Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.

    While some sub-projects have some flexibility in deciding new maintainers, generally they follow the contributor ladder. Evidence for this can be found in the community repo PRs that show contributors graduate from being a member to a reviewer to a maintainer Examples: from reviewer to maintainer and removal.

    The table below shows the overall number of reviewers (maintainers are reviewers too) for each sub-project and how many reviewers were promoted to maintainers in the past ~1 year.

    Project Reviewers (may include maintainers) Reviewers to Maintainers (last ~1 year)
    Pipelines 27 3
    Triggers 22 -
    Chains 13 2
    Results 12 3
    CLI 12 -
    Dashboard 20 -
    Operator 10 1

    The table below shows the overall number of maintainers for each sub-project and the number of emeritus maintainers.

    Project Number of maintainers Number of Emeritus maintainers
    Pipelines 13 6
    Triggers 5 4
    Chains 5 5
    Results 11 -
    CLI 5 3
    Dashboard 4 12
    Operator 5 5

  • If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.

    Generally, sub-projects follow the Tekton contributor ladder roles, and use the common automation process based on Peribolos. Core contribution guidelines and code of conduct are applicable to all repos. Some sub-projects that are in an early/experimental stage or are of a special nature (e.g. docs/website) use more maintainer discretion while adding new maintainers. Sub-projects maintain and document their own maturity status (e.g. triggers has a beta API while pipeline has a v1 API).

    The table belows documents the level of maturity of the API for sub-project that expose an API on some kind:

    Project Project API Stability
    Pipelines Stable API (v1 CRD)
    Triggers Beta API (v1beta1 CRD)
    Chains Beta (Go API)
    Results Alpha gRPC (Beta planned for 2024 Q1)
    Operator Alpha (v1alpha1 CRD)

Required

  • Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.

    The current maintainers for the main pipelines project are:

    Name Affiliation GitHub Slack
    Andrea Frittoli IBM afrittoli @Andrea Frittoli
    Christie Warwick Google bobcatfish @Christie Wilson
    Dibyo Mukherjee Google dibyom @Dibyo Mukherjee
    Jason Hall Chainguard ImJasonH @Jason Hall
    Vincent Demeester RedHat vdemeester @vdemeester
    Priti Desai IBM pritidesai @Priti Desai
    Jerop Kipruto Google jerop @Jerop Kipruto
    Lee Bernick lbernick @Lee Bernick
    Andrew Bayer Datadog abayer @Andrew Bayer
    Billy Lynch Chainguard wlynch @Billy Lynch
    Yongxuan Zhang Google yongxuanzhang @Yongxuan Zhang
    Chitrang Patel Google chitrangpatel @Chitrang
    Jerome Ju Google jeromeJu @Jerome Ju

    Tekton sub-projects each have their own maintainer teams. The source of truth for this is our org.yaml file. Each person in a .maintainers team is a maintainer for that particular sub-project. The org.yaml file is used to maintain the definition of GitHub teams and org settings in git, which provides us with historical records of changes.

  • A number of active maintainers which is appropriate to the size and scope of the project.

    Project Number of maintainers
    Pipelines 13
    Triggers 5
    Chains 5
    Results 11
    CLI 5
    Dashboard 4
    Operator 5

    The graph of PR Open to Merged shows a steady rate of PRs getting merged into the core pipelines project. The user stats chart also shows multiple active maintainers across multiple companies.

    While pipelines is the most active project, the other sub-projects have maintainers and activity from multiple contributors as well. See the user stats chart for Chains, Triggers, CLI, operator etc.

  • Code and Doc ownership in Github and elsewhere matches documented governance roles.

    This is automated using peribolos and the source of truth is maintained in git.

  • Document agreement that project will adopt CNCF Code of Conduct.

Yes, as part of the migration from CDF to CNCF.

Contributors and Community

Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.

Suggested

Required

Non public lists

Engineering Principles

Suggested

  • Roadmap change process is documented.

    The community tracks the project roadmap through GitHub projects:

    • Sub-project maintainers can add the area/roadmap to issues to add them to the roadmap
    • Related GitHub issue
    • (TBD) Add this to the community repository

  • History of regular, quality releases.

    Releases are available on GitHub and further documented in a releases.md file in each repo:

    The Tekton catalog includes several resources, each versioned individually, so releases are handled differently, not through the GitHub release tool:

    • Each new version of a resource in the catalog is stored in a dedicated folder
    • Tasks are published on a daily basis to a container registry as well as to ArtifactHub

    The Tekton community is in the process of migrating resources to smaller repos in a dedicated GitHub org, where resources maintained by the Tekton community will be versioned and released through git/GitHub.

Required

  • Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently.

From Tekton Mission and Vision:

Tekton's mission is to be the industry-standard, cloud-native CI/CD platform components and ecosystem.

The vision for this is:

  • Tekton API conformance across as many CI/CD platforms as possible
  • A rich catalog of high quality, reusable Steps and Tasks which work with Tekton conformant systems

What this vision looks like differs across different users:

  • Engineers building CI/CD systems: These users will be motivated to use Tekton and integrate it into the CI/CD systems they are using because building on top of Tekton means they don't have to re-invent the wheel and out of the box they get scalable, serverless cloud native execution
  • Engineers who need CI/CD: (aka all software engineers!) These users (including Pipeline and Task authors and Pipeline and Task users) will benefit from the rich high quality catalog of reusable components:
  • Quickly build and interact with sophisticated Pipelines
  • Be able to port Pipelines to any Tekton conformant system
  • Be able to use multiple Tekton conformant systems instead of being locked into one or being forced to build glue between multiple completely different systems
  • Use an ecosystem of tools that know how to interact with Tekton components, e.g. IDE integrations, linting, CLIs, security and policy systems

Cloud native use cases

  • Building CI/CD systems on cloud native infrastructure without having to reinvent the wheel
    • Can be used on just Kubernetes with no other additional infrastructure.
    • Can be used in tandem with other cloud native tooling - see Ecosystem section for details
  • Powerful cloud native pipelines that can be managed as plain CRDs
    • Create and manage complex pipelines for bespoke CI/CD use cases including matrix, parallel and sequential execution, error handling, input/output based dependencies, reusable common components etc.
  • Flexibility to support complex use cases including extension points such as CustomTasks that allow users to define their own implementations.
  • Secure supply chain support built-in (provenance, image attestations, trusted tasks, SLSA L3 support)
  • Loosely coupled components approach - e.g. pipelines can be used with another triggering system
  • Using declarative and other cloud native tooling (e.g. kustomize) to manage pipelines and installations
  • Sharing and using high quality reusable CI/CD components from the Catalog including the ability to have private catalogs for organizations
  • Using an open ecosystem of tolling (linters, IDE integration, UI, CLI, operator)
  • Beyond CI/CD: Tekton's flexibility and powerful pipeline abstraction allows it to support use cases such as machine learning pipelines

Differentiation in Cloud native landscape

In the CNCF landscape, there are a number of projects in the CI/CD and App delivery space. Tekton provides powerful and flexible building blocks to create cloud native CI/CD systems.

Argo Workflows is likely the most similar in that both Tekton and Argo Workflows allow users to create and run DAG based pipelines on Kubernetes. Tekton focuses mostly on CI/CD pipelines and comes with a fully featured catalog of reusable tasks - ArtifactHub has over 350 Tekton tasks. In addition, Tekton also comes with a slew of supply chain security features including provenance generation, integration with Sigstore for keyless signing and verification, and trusted resources. It is also worth noting that Tekton and Argo can provide complementary functionalities and integrate nicely - using Tekton for the CI pipeline with ArgoCD handling the deployment is a popular pattern.

  • Document what the project does, and why it does it - including viable cloud native use cases.

Tekton is a powerful, flexible, cloud-native open-source framework for creating CI/CD systems. It brings the scalability and resiliency of cloud native applications to CI/CD workloads.

Tekton consists of a set of core components, tools and a catalog. Components include:

  • Pipelines: a set of Kubernetes custom resources and controllers for defining and executing pipelines
  • Triggers: a set of Kubernetes custom resources and controllers for triggering pipelines
  • Chains: a set of SLSA compliance features for Tekton, including Sigstore integration, in-toto attestations and more
  • Results: long term queryable storage of the pipeline execution history

Tools are a web-based Dashboard, the tkn CLI and the operator.

The catalog provides users with reusable Tasks and Pipelines hosted on GitHub and ArtifactHub.

  • Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.

Roadmap is maintained on an ongoing basis project wide in this GitHub project: https://github.com/orgs/tektoncd/projects/26. Sub-projects use the area/roadmap label to add items to the roadmap.

  • Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.

Components Overview

Tekton provides an Operator which installs and updates all the other Tekton components on the cluster.

Users interface with the Tekton cluster using the Tekton Dashboard and the Tekton CLI. Additionally, users author their Tasks and Pipelines and may host them on TektonHub or ArtifactHub (catalogs) to share them openly with other Tekton users. They can also use an existing Task/Pipeline from these catalogs.

To listen to events from Event sources like Github webhook and cloud events and initiate a workflow, Tekton offers a Triggers component. At the core of it all is the Tekton Pipeline, the engine that executes the workflow (i.e. a PipelineRun and a TaskRun). Both Tekton Triggers and Pipeline, emit cloud events and metrics.

The workflow (i.e. PipelineRun and TaskRun) are watched by optional components, Tekton Chains and Tekton Results. Tekton Chains generates the in-toto provenance of the build and signs it. Tekton Results accumulates the records (Status of the TaskRun and PipelineRun CRDs and Logs) of the PipelineRuns and TaskRuns for long term searchable history.

components diagram

Software Design

Tekton defines various Kubernetes custom resources (CRDs), that let users define, trigger and execute CI/CD workflows in the form of Kubernetes workloads. Tekton core services (Pipeline, Triggers, Chains, Results) are implemented as controllers for those resources.

Tekton resources can be signed, verified and shared for reusability and embedding of an organization's best practices. Tekton provides a set of admission controllers for validating resources - custom admission controllers can be added thanks to other CNCF projects like Kyverno and OPA.

Tekton can both consume and produce CloudEvents, to implement event driven, scalable and decoupled workflows. More details about Tekton software design and concepts are available in the project’s documentation. See the following pages for an overview of the architecture:

Security

Note: this section may be augemented by a joint-assessment performed by TAG Security.

Suggested

N/A

Required

  • Clearly defined and discoverable process to report security issues.

The security policy is linked and shown in the GitHub description of the repositories github.com/tektoncd/community?tab=security-ov-file#readme.

  • Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)

  • Two factor is enforced for all org members

  • Direct pushes to branches are disabled and all merges happen using Tide

  • Access to the Github org/teams is controlled using Peribolos for automation.

  • Access to the infrastructure used for CI/releases etc. is controlled via terraform and is maintained in a private repository which is accessible to the plumbing maintainers team.

  • Document assignment of security response roles and how reports are handled.

The Tekton vulnerability management team handles security responses. Responses are coordinated through a private slack channel and using GitHub's security advisory process when needed.

  • Document Security Self-Assessment.

Tekton underwent an independent security assessment as part of the requirements to become a CDF Graduated project. See the blog post for a write up and the full report for the details.

Ecosystem

Suggested

N/A

Required

  • Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)

Current adopters include Google, IBM, RedHat, Cloudbees, Nubank, Marriott Vacations Worldwide, NuBank, OneStock. Also, there are open source projects that have adopted Tekton. Publicly document lists of adopters:

The project provided the TOC with a list of adopters for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation.

  • TOC verification of adopters.

Refer to the Adoption portion of this document.

  • Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.

  • Kubernetes - Tekton is built by extending Kubernetes using CustomResources

  • Other OSS projects that use Tekton include Shipwright, Jenkins X, Kubeflow Pipelines for Tekton, EPAM delivery platform, Automatiko

  • ArgoCD + Tekton is a popular pattern that is documented in several blogs and projects

  • CloudEvents - Tekton can emit CloudEvents and can trigger pipelines based on incoming CloudEvents

  • Sigstore, in-toto, SLSA: Tekton chains allows users to use keyless signing for provenance, produce attestations in in-toto format and implement SLSA 2+ compliant build systems.

  • OpenTelemetry, Jaeger, Prometheus: Tekton emits OpenTelemetry metrics and distributed traces that can be visualized through Prometheus and Jaeger

Additional Information

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment