Support Triggers 0.2 features in the dashboard

[a-roberts]

With the assessment done, under this task go ahead and do it, so specifically we want to:

1. Install Triggers 0.2
2. Read through Assess the move to Triggers 0.2 (Dashboard) #918 and Front End Development for Triggers UI #937
3. Make the changes and test/contribute

The assessment task (#918) should include all of the changes we'll have to make. If it does turn into something many folks can work on at once it'll be great to add more issues so we can get this done asap 😸

Obvious things: multiple bindings and interceptors

[ncskier]

/assign

[kimholmes]

@AlanGreene and @ncskier Per Brandon's note in this older issue:
#918 (comment)
"Multiple interceptors
EventListener triggers can now have multiple interceptors instead of just one. So, we must display this list of interceptors."

Does this mean the UI could turn up multiple headers per interceptor? We might need to tweak the UI if this becomes unruly due to scrolling etc.
See Carrie's current mock-ups:
#937

[ncskier]

Does this mean the UI could turn up multiple headers per interceptor?

@kimholmes not multiple headers per interceptor, but yes multiple headers per EventListener. Each interceptor has its own headers, and each EventListener can have multiple interceptors. So we could have an EventListener that looks like this:

EventListener
- Interceptor-1
  - List of headers for Interceptor-1
- Interceptor-2
  - List of headers for Interceptor-2
- Interceptor-3
  - List of headers for Interceptor-3
...

Does that answer your question? 🙂

[kimholmes]

@ncskier Yes, for some reason, I was under the impression that the headers were a child of the Interceptor. I hope the UI isn't confusing.

[ncskier]

Yes, the headers are a child of each interceptor:

EventListener
- Interceptor-1
  - List of headers for Interceptor-1
- Interceptor-2
  - List of headers for Interceptor-2
- Interceptor-3
  - List of headers for Interceptor-3

[ncskier]

@a-roberts @AlanGreene, how do we want to address backwards-compatibility? Since Triggers only has a few early alpha releases, we're assuming that there will be some breaking changes. So, I think that it makes sense to not worry about supporting v0.1.0 Triggers resources in the Dashboard.

I just want to verify that it is OK if my implementation of this issue will mean the Dashboard "breaks" when displaying v0.1.0 Triggers resources.

[AlanGreene]

What are the plans for dashboard 0.5 (inc. webhooks extension)? I see a draft release referencing triggers 0.1, do we need to get that out before bumping the triggers version or are we ok to go ahead with the update now?

[a-roberts]

@ncskier @AlanGreene good points, I wanted to get in @Megan-Wright's PR for the proper displaying of proxy request errors (mainly from a debug/serviceability perspective), so I suggest we do a 0.5.0 release that's for Triggers 0.1 and Pipeline 0.10.1 one shortly (see: today).

Then the 0.5.1 release is for Triggers 0.2 once that's ready, this gives folks a chance to use either Triggers version with a supported release.

[ncskier]

Ok, thanks for the clarification Adam! 👍

[ncskier]

Status update:

I can now display multiple bindings, and interceptors. Plus there are no more params. Here's a screenshot (note that I copied and pasted the interceptors, so they have the same name). I used an accordion to display the multiple interceptors for now, because it was easy and saves space. Feedback is always welcome 🙂 However, keep in mind the styles will probably change with issue #937.

Still to do:

• Support displaying the 3 additional built-in Triggers Interceptors (GitHub, GitLab, and CEL)
• Update tests
• Fix bugs & edge cases that I've noticed; for example, displaying Triggers without a name & displaying ServiceAccount