cncf / toc

⚖️ The CNCF Technical Oversight Committee (TOC) is the technical governing body of the CNCF Foundation.
https://cncf.io
1.65k stars 627 forks source link

[Incubation] Tekton Incubation Application #1310

Open afrittoli opened 1 month ago

afrittoli commented 1 month ago

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](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).** - Tekton source code is licensed under the [Apache 2.0](https://www.apache.org/licenses/LICENSE-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](https://github.com/tektoncd/community/blob/main/governance.md#maximum-representation) - Tekton design decisions happen in the open through the [TEP proposal process](https://github.com/tektoncd/community/blob/main/process/tep-process.md), which ensures vendor neutrality by requiring approvals from two different companies - [ ] **Review and acknowledgement of expectations for [Sandbox](https://sandbox.cncf.io) 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. - [ ] **Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.** - [Tekton Documentation](https://tekton.dev/docs/) - [Tekton Blog](https://tekton.dev/blog/) - [Tekton Community](https://tekton.dev/community/) - [Tekton Design Documents](https://github.com/tektoncd/community/blob/main/teps/README.md) ## 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](https://github.com/tektoncd/community/blob/main/governance.md), linked from the community repo [README](https://github.com/tektoncd/community/tree/main?tab=readme-ov-file#want-to-learn-how-the-project-works) - The [community docs](https://tekton.dev/community) 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](https://github.com/tektoncd/community/blob/main/process/contributor-ladder.md), came up with a [proposals process](https://github.com/tektoncd/community/blob/main/process/tep-process.md) (TEPs), and have made updates to governance to [ensure vendor neutrality](https://github.com/tektoncd/community/blob/main/governance.md#maximum-representation). - [ ] **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](https://github.com/tektoncd/community/). There is a bi-weekly community/governance [meeting](https://github.com/tektoncd/community/blob/main/working-groups.md#governing-board--community) that is open to everyone. - [ ] **Governance clearly documents [vendor-neutrality](https://contribute.cncf.io/maintainers/community/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](https://github.com/tektoncd/community/blob/main/governance.md#maximum-representation) 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](https://github.com/tektoncd/community/blob/main/process/tep-process.md#approval-requirements) 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](https://github.com/tektoncd/community/blob/main/governance). Contribution acceptance is documented in the [process docs](https://github.com/tektoncd/community/blob/main/process/README.md?plain=1#L95). - [ ] **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](https://github.com/tektoncd/community/blob/main/process/contributor-ladder.md). 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](https://github.com/tektoncd/community/blob/main/process/contributor-ladder.md). - [ ] **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](https://github.com/tektoncd/community/pull/978) to [maintainer](https://github.com/tektoncd/pipeline/commit/6d8f8a67483638da9a539c3d5bb7c84d98e92f6d) and [removal](https://github.com/tektoncd/pipeline/commit/c1b3c496aadffe92a4b0304290a20ee32afb8398). 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](https://github.com/tektoncd/pipeline/blob/e556bc734f781a90ec32e93231025bf7fc156a54/OWNERS_ALIASES#L44) | | Triggers | 5 | [4](https://github.com/tektoncd/triggers/blob/9b472899801f88cd700fe3b99bf6bb7fc88af494/OWNERS#L10) | | Chains | 5 | [5](https://github.com/tektoncd/chains/blob/2b5054ee0887083072e7ef29fbc1bcca2cc1c161/OWNERS#L16) | | Results | 11 | \- | | CLI | 5 | [3](https://github.com/tektoncd/cli/blob/f3422c77187ed427f8f8c489fce828d39bc73fa9/OWNERS#L10) | | Dashboard | 4 | [12](https://github.com/tektoncd/dashboard/blob/9fe4d680ed8a3bf24cc2b90e0190774b3fd8e223/OWNERS#L11) | | Operator | 5 | [5](https://github.com/tektoncd/operator/blob/2f4fc77f7bbcbed888ed2c58c24372219368bfc7/OWNERS#L13) | - [ ] **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](https://tektoncd.slack.com/team/UJ411P2CC) | | Christie Warwick | Google | bobcatfish | [@Christie Wilson](https://tektoncd.slack.com/team/UJ6DECY78) | | Dibyo Mukherjee | Google | dibyom | [@Dibyo Mukherjee](https://tektoncd.slack.com/team/UJ73HM7PZ) | | Jason Hall | Chainguard | ImJasonH | [@Jason Hall](https://tektoncd.slack.com/team/UJ3MCRRRA) | | Vincent Demeester | RedHat | vdemeester | [@vdemeester](https://tektoncd.slack.com/team/UHSQGV1L3) | | Priti Desai | IBM | pritidesai | [@Priti Desai](https://tektoncd.slack.com/team/UKGR1JF7B) | | Jerop Kipruto | Google | jerop | [@Jerop Kipruto](https://tektoncd.slack.com/team/U011DPQSP0V) | | Lee Bernick | | lbernick | [@Lee Bernick](https://tektoncd.slack.com/team/U02JB9QRWPM) | | Andrew Bayer | Datadog | abayer | [@Andrew Bayer](https://tektoncd.slack.com/team/UJ6DJ4MSS) | | Billy Lynch | Chainguard | wlynch | [@Billy Lynch](https://tektoncd.slack.com/team/UJ7BLGSB0) | | Yongxuan Zhang | Google | yongxuanzhang | [@Yongxuan Zhang](https://tektoncd.slack.com/team/U02R7K08L01) | | Chitrang Patel | Google | chitrangpatel | [@Chitrang](https://tektoncd.slack.com/team/U03BUB3KJ3B) | | Jerome Ju | Google | jeromeJu | [@Jerome Ju](https://tektoncd.slack.com/team/U03PFAKRS65) | Tekton sub-projects each have their own maintainer teams. The source of truth for this is our [`org.yaml`](https://github.com/tektoncd/community/blob/main/org/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](https://tekton.devstats.cd.foundation/d/16/opened-to-merged?orgId=1&var-period=d7&var-repogroup_name=tektoncd%2Fpipeline&from=now-6M&to=now) shows a steady rate of PRs getting merged into the core pipelines project. The [user stats chart](https://tekton.devstats.cd.foundation/d/48/users-statistics-by-repository-group?orgId=1&from=now-5y&to=now&var-period=m&var-metric=contributions&var-repogroup_name=tektoncd%2Fpipeline&var-users=All) 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](https://tekton.devstats.cd.foundation/d/48/users-statistics-by-repository-group?orgId=1&from=now-5y&to=now&var-period=m&var-metric=contributions&var-repogroup_name=tektoncd%2Fchains&var-users=All), [Triggers](https://tekton.devstats.cd.foundation/d/48/users-statistics-by-repository-group?orgId=1&from=now-5y&to=now&var-period=m&var-metric=contributions&var-repogroup_name=tektoncd%2Ftriggers&var-users=All), [CLI](https://tekton.devstats.cd.foundation/d/48/users-statistics-by-repository-group?orgId=1&from=now-5y&to=now&var-period=m&var-metric=contributions&var-repogroup_name=tektoncd%2Fcli&var-users=All), [operator](https://tekton.devstats.cd.foundation/d/48/users-statistics-by-repository-group?orgId=1&from=now-5y&to=now&var-period=m&var-metric=contributions&var-repogroup_name=tektoncd%2Foperator&var-users=All) 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](https://github.com/tektoncd/community/tree/main/org). - [ ] **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](https://www.contributor-covenant.org/version/1/4/code-of-conduct.html) v1.4. It's linked to all Tekton repos via [github.com/tektoncd/.github/blob/main/.github/CODE_OF_CONDUCT.md](https://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](https://www.contributor-covenant.org/version/1/4/code-of-conduct.html) 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. - [pipeline](https://github.com/tektoncd/pipeline/blob/main/OWNERS_ALIASES) - [triggers](https://github.com/tektoncd/triggers/blob/main/OWNERS) - [cli](https://github.com/tektoncd/cli/blob/main/OWNERS) - [dashboard](https://github.com/tektoncd/dashboard/blob/main/OWNERS) - [operator](https://github.com/tektoncd/operator/blob/main/OWNERS) - [chains](https://github.com/tektoncd/chains/blob/main/OWNERS) - [catalog](https://github.com/tektoncd/catalog/blob/main/OWNERS) ## 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](https://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.md` file 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.md](https://github.com/tektoncd/pipeline/blob/main/CONTRIBUTING.md) - For 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/](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: - [Tekton Slack!](https://join.slack.com/t/tektoncd/shared_invite/zt-25lfy2wk3-DH1FKFPWG2QQU~EzHa0Vsg) - [Twitter](https://twitter.com/tektoncd) - [Tekton developers mailing list](https://groups.google.com/forum/#!forum/tekton-dev) - [Tekton users mailing list](https://groups.google.com/forum/#!forum/tekton-users) - [Working groups and meetings](https://github.com/tektoncd/community/blob/main/working-groups.md) (also see details about each working group at [https://github.com/tektoncd/community/blob/main/working-groups.md](https://github.com/tektoncd/community/blob/main/working-groups.md)) - [The Tekton Developer's shared Drive](https://drive.google.com/drive/u/0/folders/0AFOvPxM9MpebUk9PVA) (join tekton-dev mailing list for access) Non public lists: - Governance mailing list: [tekton-governance](https://groups.google.com/g/tekton-governance/about) - Security reports: [https://groups.google.com/g/tekton-vmt](https://groups.google.com/g/tekton-vmt) - Code of conduct: [https://groups.google.com/g/tekton-code-of-conduct](https://groups.google.com/g/tekton-code-of-conduct) - [ ] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.** - [Tekton Calendar](https://github.com/tektoncd/community/blob/main/contact) - [Details of working groups](https://github.com/tektoncd/community/blob/main/working-groups.md) - [ ] **Documentation of how to contribute, with increasing detail as the project matures.** - As mentioned above, each project has a [CONTRIBUTING.md](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](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](https://tekton.devstats.cd.foundation/d/9/developer-activity-counts-by-repository-group-table?orgId=1&var-period_name=Last%206%20months&var-metric=contributions&var-repogroup_name=All&var-country_name=All)) - The commit history for the [org.yaml file](https://github.com/tektoncd/community/commits/main/org/org.yaml) 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](https://github.com/tektoncd/community?tab=readme-ov-file#want-to-get-involved) 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: - Sub-project maintainers can add the `area/roadmap` to issues to add them to the roadmap - [Related GitHub issue](https://github.com/tektoncd/community/issues/814) - (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: - Pipeline: [GitHub](https://github.com/tektoncd/pipeline/releases), [`releases.md`](https://github.com/tektoncd/pipeline/blob/main/releases.md) - Triggers: [GitHub](https://github.com/tektoncd/triggers/releases), [`releases.md`](https://github.com/tektoncd/triggers/blob/main/releases.md) - CLI: [GitHub](https://github.com/tektoncd/cli/releases), [`releases.md`](https://github.com/tektoncd/cli/blob/main/releases.md) - Dashboard: [GitHub](https://github.com/tektoncd/dashboard/releases), [`releases.md`](https://github.com/tektoncd/dashboard/blob/main/releases.md) - Operator: [GitHub](https://github.com/tektoncd/operator/releases), [`releases.md`](https://github.com/tektoncd/operator/blob/main/releases.md) - Chains: [GitHub](https://github.com/tektoncd/chains/releases), [`releases.md`](https://github.com/tektoncd/chains/blob/main/releases.md) 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](https://github.com/tektoncd/catalog?tab=readme-ov-file#using-tasks-through-bundles) as well as to [ArtifactHub](https://artifacthub.io/packages/search?kind=7&kind=11&ts_query_web=tekton&sort=relevance&page=1) The Tekton community is in the process of migrating resources to smaller repos in a dedicated [GitHub org](https://github.com/tektoncd-catalog), 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](https://github.com/tektoncd/community/blob/main/roadmap.md#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](https://github.com/tektoncd/community/blob/main/user-profiles.md): - Engineers building CI/CD systems: [These users](https://github.com/tektoncd/community/blob/main/user-profiles.md#3-platform-builder) 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](https://github.com/tektoncd/community/blob/main/user-profiles.md#1-pipeline-and-task-authors) and [Pipeline and Task users](https://github.com/tektoncd/community/blob/main/user-profiles.md#2-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](?tab=t.0#heading=h.ix3gazp6fpos) 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](https://landscape.cncf.io/guide#app-definition-and-development--continuous-integration-delivery). 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](https://artifacthub.io/packages/search?kind=7&ts_query_web=tekton&sort=relevance&page=1). In addition, Tekton also comes with a slew of supply chain security [features](https://cd.foundation/blog/2023/05/08/new-supply-chain-security-features-in-tekton/) 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](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: - [https://tekton.dev/docs/concepts/concept-model/](https://tekton.dev/docs/concepts/concept-model/) - [https://tekton.dev/docs/concepts/overview/](https://tekton.dev/docs/concepts/overview/) - [https://tekton.dev/docs/concepts/supply-chain-security/](https://tekton.dev/docs/concepts/supply-chain-security/) - [https://tekton.dev/docs/triggers/](https://tekton.dev/docs/triggers/) - [ ] **Document the project's release process.** - [Community Wide Release Process](https://github.com/tektoncd/community/blob/main/releases.md) - [Pipeline Release Cadence and Process](https://github.com/tektoncd/pipeline/blob/main/releases.md) - [Triggers Release Cadence and Process](https://github.com/tektoncd/triggers/blob/main/releases.md) - [Chains Release Cadence and Process](https://github.com/tektoncd/chains/blob/main/releases.md) - [Dashboard Release Cadence and Process](https://github.com/tektoncd/dashboard/blob/main/releases.md) - [Operator Release Cadence and Process](https://github.com/tektoncd/operator/blob/main/releases.md) - [CLI Release Cadence and Process](https://github.com/tektoncd/cli/blob/main/releases.md) ## 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](https://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](https://github.com/tektoncd/infra) 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](https://cd.foundation/blog/2022/08/26/tekton-security-review-completed/) for a write up and [the full report for the details](https://cd.foundation/wp-content/uploads/sites/78/2022/08/Tekton-Report-Public-Final.pdf). - [ ] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.** Links to passing badges: - [pipelines](https://www.bestpractices.dev/en/projects/4020) - [triggers](https://www.bestpractices.dev/en/projects/6527) - [chains](https://www.bestpractices.dev/en/projects/6408) - [cli](https://www.bestpractices.dev/en/projects/6510) - [dashboard](https://www.bestpractices.dev/en/projects/6543) - [operator](https://www.bestpractices.dev/en/projects/6548) ## 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: - [adopters.md](https://github.com/tektoncd/community/blob/main/adopters.md) - [tektoncd/friends](https://github.com/tektoncd/friends) - [Solarwinds](https://www.youtube.com/watch?v=1-tMRxqMwTQ) - [Ozone](https://www.ozone.one/) - [Kaiju.ci](Kaiju.ci) - More companies adopt Tekton but are not (yet) on the adopter list - [ ] **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)** - Public Adopters: [github.com/tektoncd/community/blob/main/adopters.md](https://github.com/tektoncd/community/blob/main/adopters.md) - Vendors: Google, RedHat/IBM - Tentative End-Users (to be confirmed): NuBank, Solarwinds, Apple 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 3 compliant build systems. - OpenTelemetry, Jaeger, Prometheus: Tekton emits OpenTelemetry metrics and distributed traces that can be visualized through Prometheus and Jaeger ## Additional Information
angellk commented 1 month ago

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.

schristoff commented 2 weeks ago

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)