Proposal: Change API Group for triggers

[vdemeester]

While experimenting on tektoncd/pipeline#1773, I experimented with api groups (tekton.dev) and commented out that, I wished, triggers would have a different API group than tektoncd/pipeline.

(make it easier to detect the precense of trigger without having to know which types it exposes — right now.. | grep tekton.dev returns pipeline and triggers 😛).

It might be a bit late to change tektoncd/pipeline api group, but I feel we could do it for tektoncd/triggers given we are still in 0.1 👼.

The proposal would be to use triggers.tekton.dev as APIGroup instead of tekton.dev (making it easier to detect by looking at existing APIs).

@vtereso @dibyom @bobcatfish @iancoffey @wlynch wdyt ?

/area api
/kind question
/kind feature

[dibyom]

Sounds like a reasonable change to me.
Are there any other benefits besides detecting the presence of Triggers?

Also, doesn't this mean we'd have to update all bindings/templates/eventlistener yamls to the new apiGroup. Would the mutating webhook help here as well?

[vdemeester]

Sounds like a reasonable change to me.
Are there any other benefits besides detecting the presence of Triggers?

Not much, just that I feel it "isolate" each project each project project.tekton.dev ; under the same umbrella tekton.dev 😝.

Also, doesn't this mean we'd have to update all bindings/templates/eventlistener yamls to the new apiGroup. Would the mutating webhook help here as well?

Good question, I think the webhook could be setup to listen to both as a backward compatible mechanism but I am not sure… I didn't experiment with that yet 😅

[wlynch]

👍

Related: Having a separate API Group / Namespace would also have prevented #262.

A similar pattern can be found in other projects Knative (serving.knative.dev, eventing.knative.dev, messaging.knative.dev, internal.knative.dev, ...), Istio (config.istio.io, networking.istio.io, ...)

[dibyom]

/assign

[ncskier]

@dibyom and I talked offline about moving this issue to the beginning of v0.4.0 development, so that we don't introduce a breaking change right before releasing v0.3.0. So, I'm going to move this issue to the v0.4.0 Milestone. We'll want to merge the code at the beginning of the release development cycle so that we can have a good amount of time for testing 👍