A Tekton Enhancement Proposal (TEP) is a way to propose, communicate and coordinate on new efforts for the Tekton project. You can read the full details of the project in TEP-1.
A standardized development process for Tekton is proposed in order to
- provide a common structure and clear checkpoints for proposing changes to Tekton
- ensure that the motivation for a change is clear
- allow for the enumeration stability milestones and stability graduation criteria
- persist project information in a Version Control System (VCS) for future Tekton users and contributors
- support the creation of high value user facing information such
as:
- an overall project development roadmap
- motivation for impactful user facing changes
- ensure community participants are successfully able to drive changes to completion across one or more releases while stakeholders are adequately represented throughout the process
This process is supported by a unit of work called a Tekton Enhancement Proposal (TEP). A TEP attempts to combine aspects of the following:
- feature, and effort tracking document
- a product requirements document
- design document
into one file which is created incrementally in collaboration with one or more Working Groups (WGs).
This process does not block authors from doing early design docs using any means. It does not block authors from sharing those design docs with the community (during Working groups, on Slack, GitHub, ….
This process acts as a requirement when a design docs is ready to be
implemented or integrated in the tektoncd projects. In other words,
a change that impact other tektoncd projects or users cannot be
merged if there is no TEP associated with it.
This TEP process is related to
- the generation of an architectural roadmap
- the fact that the what constitutes a feature is still undefined
- issue management
- the difference between an accepted design and a proposal
- the organization of design proposals
This proposal attempts to place these concerns within a general framework.
See TEP-1 for more details.
The TEP OWNERS are the main owners of the following projects:
To create a new TEP, use the teps script:
$ ./teps/tools/teps.py new --title "The title of the TEP" --author nick1 --author nick2The script will allocate a new valid TEP number, set the status to "proposed" and set the start and last updated dates.
Note that the picked number is not "locked" until a PR is created.
The PR title shall be in the format TEP-XXXX: <tep-title>.
To help a TEP to be approved quickly, it can be effective for the initial content of the TEP to include the high level description and use cases, but no design, so reviewers can agree that the problems described make sense to address before deciding how to address them. Sometimes this can be too abstract and it can help ground the discussion to include potential designs as well - but usually this will mean people will want to agree to the design before merging and it can take longer to get consensus about the design to pursue.
The TEP PR might fail CI if a TEP number conflict is detected, or if
there is a merge conflict in the TEP table. In case that happens, use
the teps.py renumber command to refresh your PR:
./teps.py renumber --update-table <path-to-tep-file>
The command will update the TEP in the file name and content with a new available TEP number, it will refresh the TEPs table and it will present a list of git commands that can be used to update the commit.
TEP should be merged as soon as possible in the proposed state. As
soon as a general consensus is reached that the TEP, as described
make sense to pursue, the TEP can be merged. The authors can then add the
design and update the missing part in follow-up pull requests which moves the TEP to implementable.
TEP should be approved by at least two owners from different company. This should prevent a company to force push a TEP (and thus a feature) in the tektoncd projects.
- After a TEP PR has been created, in
the next API working group meeting,
we will try to find 2 qualified assignees to review (from 2 different companies as described above) and will
assign
them to the PR.
- If we cannot find 2 reviewers in the meeting, someone in the meeting will be take the action to find reviewers offline (e.g. over slack or tekton-dev).
- Once reviewers have been assigned, they should give initial feedback on the PR by the next API working group meeting at the latest.
Reviewers should use /approve to indicate that they approve of the PR being merged. Once all assigned reviewers
have approved the PR, the final /lgtm can be added in
the next API working group meeting or sooner
by anyone with permission to if needed. If a reviewer has not submitted an /approve, this is taken to mean that the
reviewer either a) hasn't done an initial review yet (see SLO above) or b) wants to see changes in the TEP before
approving. Whenever possible we will try to get an explicit /approve from all assigned reviewers before merging, but
we can always fall back on our strict approval requirements if needed.
Why don't we use GitHub reviewers instead of assignees? If we want to do that we need to turn off Prow's auto assignment of reviewers; there is no guarantee the auto assigned reviewers are the appropriate reviewers. See discussion.
This is the complete list of Tekton teps:
| TEP | Title | Status | Last Updated |
|---|---|---|---|
| TEP-0001 | Tekton Enhancement Proposal Process | implemented | 2020-06-11 |
| TEP-0002 | Custom Tasks | implemented | 2021-12-15 |
| TEP-0003 | Tekton Catalog Organization | implemented | 2021-02-09 |
| TEP-0004 | Task Results in Final Tasks | implemented | 2021-06-03 |
| TEP-0005 | Tekton OCI Bundles | implemented | 2022-01-04 |
| TEP-0006 | Tekton Metrics | proposed | 2020-07-13 |
| TEP-0007 | Conditions Beta | implemented | 2021-06-03 |
| TEP-0008 | Support Knative Service for Triggers EventListener Pod | implementable | 2020-08-25 |
| TEP-0009 | Trigger CRD | implementable | 2020-09-08 |
| TEP-0010 | Optional Workspaces | implemented | 2020-10-15 |
| TEP-0011 | redirecting-step-output-streams | implementable | 2020-11-02 |
| TEP-0012 | API Specification | implemented | 2021-12-14 |
| TEP-0014 | Step Timeout | implemented | 2021-12-13 |
| TEP-0015 | pending-pipeline-run | implemented | 2020-09-10 |
| TEP-0016 | Concise Embedded TriggerBindings | implemented | 2020-09-15 |
| TEP-0019 | Other Arch Support | proposed | 2020-09-30 |
| TEP-0020 | s390x Support | implemented | 2021-06-04 |
| TEP-0021 | Tekton Results API | implementable | 2020-10-26 |
| TEP-0022 | Triggers - Immutable Input Events | implementable | 2020-09-29 |
| TEP-0023 | 0023-Implicit-parameter-mapping | implemented | 2021-12-15 |
| TEP-0024 | Embedded TriggerTemplates | implemented | 2020-10-01 |
| TEP-0025 | Hermetic Builds | implementable | 2020-09-11 |
| TEP-0026 | interceptor-plugins | implementable | 2020-10-08 |
| TEP-0027 | HTTPS Connection to Triggers EventListener | implementable | 2020-11-01 |
| TEP-0028 | task-exec-status-at-runtime | implemented | 2021-06-03 |
| TEP-0029 | step-and-sidecar-workspaces | implementable | 2020-10-02 |
| TEP-0030 | workspace-paths | proposed | 2020-10-18 |
| TEP-0031 | tekton-bundles-cli | implemented | 2021-03-26 |
| TEP-0032 | Tekton Notifications | proposed | 2020-11-18 |
| TEP-0033 | Tekton Feature Gates | implemented | 2021-12-16 |
| TEP-0035 | document-tekton-position-around-policy-authentication-authorization | implementable | 2020-12-09 |
| TEP-0036 | Start Measuring Tekton Pipelines Performance | proposed | 2020-11-20 |
| TEP-0037 | Remove gcs-fetcher image |
implementing | 2021-01-27 |
| TEP-0038 | Generic Workspaces | proposed | 2020-12-11 |
| TEP-0039 | Add Variable retries and retry-count |
proposed | 2021-01-31 |
| TEP-0040 | Ignore Step Errors | implemented | 2021-08-11 |
| TEP-0041 | Tekton Component Versioning | implementable | 2021-04-26 |
| TEP-0042 | taskrun-breakpoint-on-failure | implemented | 2021-12-10 |
| TEP-0044 | Data Locality and Pod Overhead in Pipelines | proposed | 2022-01-26 |
| TEP-0045 | WhenExpressions in Finally Tasks | implemented | 2021-06-03 |
| TEP-0046 | Finally tasks execution post pipelinerun timeout | implemented | 2021-12-14 |
| TEP-0047 | Pipeline Task Display Name | proposed | 2021-02-10 |
| TEP-0048 | Task Results without Results | proposed | 2021-06-11 |
| TEP-0049 | Aggregate Status of DAG Tasks | implemented | 2021-06-03 |
| TEP-0050 | Ignore Task Failures | proposed | 2021-02-19 |
| TEP-0051 | ppc64le Support | proposed | 2021-01-28 |
| TEP-0052 | Tekton Results: Automated Run Resource Cleanup | implementable | 2021-03-22 |
| TEP-0053 | Nested Triggers | implementable | 2021-04-15 |
| TEP-0056 | Pipelines in Pipelines | proposed | 2021-08-16 |
| TEP-0057 | Windows support | proposed | 2021-03-18 |
| TEP-0058 | Graceful Pipeline Run Termination | implemented | 2021-12-15 |
| TEP-0059 | Skipping Strategies | implemented | 2021-08-23 |
| TEP-0060 | Remote Resource Resolution | implementable | 2021-11-01 |
| TEP-0061 | Allow custom task to be embedded in pipeline | implemented | 2021-05-26 |
| TEP-0062 | Catalog Tags and Hub Categories Management | implemented | 2021-12-15 |
| TEP-0063 | Workspace Dependencies | proposed | 2021-04-23 |
| TEP-0066 | Dogfooding Tekton | proposed | 2021-05-16 |
| TEP-0067 | Tekton Catalog Pipeline Organization | implementable | 2021-02-22 |
| TEP-0069 | Support retries for custom task in a pipeline. | implemented | 2021-12-15 |
| TEP-0070 | Platform support in Tekton catalog | proposed | 2021-06-02 |
| TEP-0071 | Custom Task SDK | proposed | 2021-06-15 |
| TEP-0072 | Results: JSON Serialized Records | implementable | 2021-07-26 |
| TEP-0073 | Simplify metrics | proposed | 2021-11-01 |
| TEP-0074 | Deprecate PipelineResources | proposed | 2021-11-05 |
| TEP-0079 | Tekton Catalog Support Tiers | proposed | 2022-01-25 |
| TEP-0080 | Support domain-scoped parameter/result names | implemented | 2021-08-19 |
| TEP-0081 | Add Chains sub-command to the CLI | implementable | 2021-10-21 |
| TEP-0082 | Workspace Hinting | proposed | 2021-10-26 |
| TEP-0083 | Scheduled and Polling runs in Tekton | proposed | 2021-09-13 |
| TEP-0084 | end-to-end provenance collection | proposed | 2021-09-16 |
| TEP-0085 | Per-Namespace Controller Configuration | proposed | 2021-10-14 |
| TEP-0088 | Tekton Results - Record Summaries | proposed | 2021-10-01 |
| TEP-0089 | Non-falsifiable provenance support | proposed | 2022-01-18 |
| TEP-0090 | Matrix | proposed | 2021-11-08 |
| TEP-0094 | Configuring Resources at Runtime | implementable | 2021-11-29 |
| TEP-0096 | Pipelines V1 API | proposed | 2021-12-13 |
| TEP-0098 | Workflows | proposed | 2021-12-06 |
| TEP-0100 | Embedded TaskRuns and Runs Status in PipelineRuns | proposed | 2022-01-29 |