[Incubation] Tekton Incubation Application #1310
Comments
|
Looking forward to seeing the Tekton maintainers in TAG App Delivery on May 15. For TOC, TAG and any community members, add to your calendar to join. |
|
Tekton presented at TAG App Delivery on on 05/15/24. The timestamped recording is here. Tekton discussed their roadmap, which included multiple features to provide core stable features for their GA release. Their governing board has 3+ companies in representation, and no company can have more than 2 members to ensure a diverse group. Their primary use case as a CI/CD tool means they are often combined with other tools that are also open source projects (Flux, ArgoCD), where they stated they focus on collaboration with those communities. They have no explicit documentation on handling multi tenancy, but advised the multi tenancy can be achieved by utilizing an EventListener which can be scoped to different namespaces. They seem to have been supporting multi tenancy for a long time, based off this issue. They expose Otel metrics, distributed tracing information, expose events, and knative events. (1,2,3) |
|
Hi, is there any update on the status of this? What's the next step and/or blocker? |
|
Hi @imjasonh - the TOC is currently in a KubeCon freeze. Post freeze in 2 weeks, TOC members will be assigned projects according to the queue. You can see the project board here: https://github.com/orgs/cncf/projects/27/views/9 Tekton looks to be currently 10th in the queue. |
|
@dims will triage |
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:
Application Process Principles
Suggested
N/A
Required
Scheduled for 15.05.2024, Draft slides: here
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.
Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.
Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.
Tekton Documentation
Tekton Blog
Tekton Community
Tekton Design Documents
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.
The table below shows the overall number of maintainers for each sub-project and the number of emeritus maintainers.
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:
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:
Tekton sub-projects each have their own maintainer teams. The source of truth for this is our
org.yamlfile. Each person in a.maintainersteam is a maintainer for that particular sub-project. Theorg.yamlfile 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.
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.
CNCF Code of Conduct is cross-linked from other governance documents.
Tekton's code of conduct is based on the Contributor Covenant v1.4. It's linked to all Tekton repos via github.com/tektoncd/.github/blob/main/.github/CODE_OF_CONDUCT.md.
We will update the project code of conduct to the CNCF one, which based on the Contributor Covenant v2.0.
All subprojects, if any, are listed.
Tekton is made of a collection of sub-projects. See the "Components Overview" section for more details.
Contributors and Community
Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
Suggested
Contributor ladder with multiple roles for contributors.
Our contributor ladder: github.com/tektoncd/community/blob/main/process/contributor-ladder.md is documented as part of the community docs.
Required
Clearly defined and discoverable process to submit issues or changes.
Each sub-project has a
CONTRIBUTING.mdfile that describes how to contribute to the project. Common contribution guidelines across all repos are documented in the community repo and linked to by sub-projects. Example: https://github.com/tektoncd/pipeline/blob/main/CONTRIBUTING.mdFor opening issues, GitHub issue templates are used.
Project must have, and document, at least one public communications channel for users and/or contributors.
We have multiple channels for folks to reach out, all linked from https://tekton.dev/community/.
List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.
Public lists:
Non public lists:
Up-to-date public meeting schedulers and/or integration with CNCF calendar.
Tekton Calendar
Details of working groups
Documentation of how to contribute, with increasing detail as the project matures.
As mentioned above, each project has a CONTRIBUTING.md file. Since pipeline is the most mature project, it has the most detailed guide - see https://github.com/tektoncd/pipeline/blob/main/CONTRIBUTING.md
There is also a contributor ladder that documents how contributors can get to maintainer status
Demonstrate contributor activity and recruitment.
In the last 6 months, we have 60+ contributors who have made at least 10 contributions (link)
The commit history for the org.yaml file shows the growth of contributors
Tekton has a contributor ladder with a low bar of entry for the initial roles, to attract new contributors and clear contributing guidelines, with links to help discover good first issues.
Tekton participates in events like Hacktoberfest to attract new contributors.
Engineering Principles
Suggested
Roadmap change process is documented.
The community tracks the project roadmap through GitHub projects:
area/roadmapto issues to add them to the roadmapHistory of regular, quality releases.
Releases are available on GitHub and further documented in a
releases.mdfile in each repo:releases.mdreleases.mdreleases.mdreleases.mdreleases.mdreleases.mdThe Tekton catalog includes several resources, each versioned individually, so releases are handled differently, not through the GitHub release tool:
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:
The vision for this is:
What this vision looks like differs across different users:
Cloud native use cases
Building CI/CD systems on cloud native infrastructure without having to reinvent the wheel
Powerful cloud native pipelines that can be managed as plain CRDs
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 installationsSharing 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:
Tools are a web-based Dashboard, the
tknCLI 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.
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:
Document the project's release process.
Community Wide Release Process
Pipeline Release Cadence and Process
Triggers Release Cadence and Process
Chains Release Cadence and Process
Dashboard Release Cadence and Process
Operator Release Cadence and Process
CLI Release Cadence and Process
Security
Note: this section may be augemented by a joint-assessment performed by TAG Security.
Suggested
N/A
Required
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.
Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.
Links to passing badges:
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:
Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list 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.
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 3 compliant build systems.
OpenTelemetry, Jaeger, Prometheus: Tekton emits OpenTelemetry metrics and distributed traces that can be visualized through Prometheus and Jaeger
Additional Information
The text was updated successfully, but these errors were encountered: