- Add more docs, and have it publish as part of the tekton.dev/docs website.
- Highlight the benefit of using the operator, and mainly what pain it solves
An acceptance criteria for this would be to use the operator in our own CI (aka dogfooding).
As of today, the operator is capable of installing Pipeline, Triggers and the dasbhoard. We may want to support shipping more components
- New "graduated" components
- custom tasks
- other projects
Today, we are shipping ClusterTask only for the OpenShift target. We should aim towards shipping this for all targets (k8s, …)
User should be able to get tkn and install, upgrade and manage the
operator lifecycle directly from it. This should help adoption as well.
In case of a failed upgrade, it should be possible to roll-back into the previous known good state.
We are currently targeting and releasing only two target:
- Vanilla k8s
- OpenShift
We should aim to support more, starting with GKE. GKE is a easy target as we could use this in dogfooding. An idea of what could be specific for GKE is around the ingress configuration, …
The operator codebase integrates all tektoncd component into one place, it is a critical piece and need to be heavily tested so that we feel confident to release it.
- Upgrade tests
- Running component tests on top of an operator installation
- etc…
- Automated relases
- Automated publication on OperatorHub
- More often (monthly)
- Better management of the payloads (releases yamls) Today, we do some manual changes in order to release, we should aim towards taking the upstream releases yamls as is and fix anything programmatically (if need be).
Enable metrics on the operator, to be able to gather information on the health of managed components from the operator.