Normal High Level Summary
Enhance the Operator installation user experience by allowing users to modify TektonConfig default values prior to installation.
Currently, users must perform multiple post-installation steps to adjust configuration values (such as nodeSelector, storageClass, or component enablement).
By adding a configuration step between selecting the Pipelines Operator and clicking Install, users can customize defaults upfront — simplifying workflows and reducing post-installation edits.
Goals
- Improve the user experience during Pipelines Operator installation.
- Enable users to configure TektonConfig defaults (e.g., nodeSelector, storageClass, component toggles) before installation.
- Reduce the need for post-installation reconfiguration steps.
- Streamline setup for users with specific cluster or component requirements.
Who Benefits
- Cluster administrators and DevOps engineers deploying Tekton Pipelines.
- Users who maintain custom infrastructure configurations (e.g., constrained nodes, custom storage).
Current vs Future State:
| Current State | Future State |
|---|---|
| Users install Pipelines Operator, then manually edit TektonConfig CR post-installation to adjust values. | Users can define these values during installation, making setup faster, simpler, and less error-prone. |
Requirements
| Requirement | Notes | Is MVP |
|---|---|---|
| Add configuration option in the UI between Operator selection and installation. | Should expose editable TektonConfig parameters with sensible defaults. | Yes |
| Allow users to modify nodeSelector values. | Optional customization field. | Yes |
| Allow users to specify storageClass for StatefulSets. | Helps adapt to different cluster storage setups. | Yes |
| Allow users to enable/disable specific Tekton components. | E.g., disable triggers or dashboard if not required. | Yes |
| Persist user-specified values in generated TektonConfig CR. | Allow users to specify pruning conifgs before install | Yes |
| Provide validation and tooltips for each editable field. | Improves usability and reduces errors. | No could be (Future Enhancement) |
Out of scope
<Defines what is not included in this story>
Dependencies
< Link or at least explain any known dependencies. >
Background, and strategic fit
< What does the person writing code, testing, documenting need to know? >
Assumptions
< Are there assumptions being made regarding prerequisites and dependencies?>
< Are there assumptions about hardware, software or people resources?>
Customer Considerations
< Are there specific customer environments that need to be considered (such as working with existing h/w and software)?>
Documentation Considerations
< What educational or reference material (docs) is required to support this product feature? For users/admins? Other functions (security officers, etc)? >
What does success look like?
< Does this feature have doc impact? Possible values are: New Content, Updates to existing content, Release Note, or No Doc Impact?>
QE Contact
< Are there assumptions being made regarding prerequisites and dependencies?>
< Are there assumptions about hardware, software or people resources?>
Impact
< If the feature is ordered with other work, state the impact of this feature on the other work>
Related Architecture/Technical Documents
<links>
Done Checklist
- Acceptance criteria are met
- Non-functional properties of the Feature have been validated (such as performance, resource, UX, security or privacy aspects)
- User Journey automation is delivered
- Support and SRE teams are provided with enough skills to support the feature in production environment
- links to