Add design principles on CustomRun API #1010
Conversation
CustomRun is different from other Tekton APIs because its API is implemented by custom run controllers, rather than in-tree controllers. Therefore, adding new fields to this API should be done with extra caution. This commit adds a design principle providing guidance on whether a new field should go in the CustomRun API or left to custom run controllers to support as part of the custom spec or custom status, based on whether a feature is applicable to all CustomRuns or just a feature of some of them.
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
tekton-robot
added
the
size/XS
|
/assign @jerop @pritidesai I'd love your feedback on this-- based on previous customrun discussions and jumping off discussion on tektoncd/pipeline#6532 (comment) @tektoncd/core-maintainers FYI, would appreciate any feedback here Motivation here was the fact that we decided not to include |
| 1. [Avoid implementing templating logic](https://docs.google.com/document/d/1h_3vSApIsuiwGkrqSiegi4NVaYG4oVzBquGAhIN6qGM/edit#heading=h.6kxvcvm7rs3r); prefer variable replacement. | ||
| 1. Avoid implementing our own expression syntax; when required prefer existing languages which are widely used and include supporting development tools. | ||
| 1. In TEPs, discuss how the proposal affects the flexibility of Tekton and demonstrate that any specific/opinionated choices are necessary but extensible. | ||
| 1. Before adding an optional field to the spec or status of `CustomRun`, consider |
There was a problem hiding this comment.
This feels very specific to Pipelines. Perhaps somewhere in the pipelines documentation is a better place for this?
Maybe https://github.com/tektoncd/pipeline/tree/main/docs/developers?
There was a problem hiding this comment.
I agree, Triggers' ClusterInterceptor is also similar in that we except external users to implement instead of just in-tree implementations.
There was a problem hiding this comment.
Thanks for the feedback! I was trying to think of a more general way to express this since I know we have multiple api extension points in tekton projects but I think it'll be too confusing/generic-- I'll open a PR for this in pipelines instead.
4 participants
CustomRun is different from other Tekton APIs because its API is implemented by custom run controllers, rather than in-tree controllers. Therefore, adding new fields to this API should be done with extra caution. This commit adds a design principle providing guidance on whether a new field should go in the CustomRun API or left to custom run controllers to support as part of the custom spec or custom status, based on whether a feature is applicable to all CustomRuns or just a feature of some of them.