Missing features: Webhook Details and Execution History

[abhinavrastogi-harness]

Few missing capabilities today:

1. Webhook listing page doesn't show enough data about the webhook.. eg. what events are selected, status (hook is executing successfully or not etc)

2. There is no way to view the details of a webhook. Eg. today Gitness allows you to "click into" a webhook, and it opens the "Edit Webhook" page, which is not ideal, but it works to show all the details.

3. When setting up webhooks, users may need to debug if/why the webhook may not be working. For this we show the recent deliveries and payloads.

[3em]

Hi @abhinavrastogi-harness ,

Once the design is ready, we will take over the improvements for the webhook list on our team. I just wanted to ask, which data from the API response (shown in the screenshot) is responsible for displaying the "executing" status?

---

Regarding the executions section, I suggest assigning it to the PIPE team as soon as the design is ready.
Unfortunately, we don’t have any information about the query hooks API for this section to start working on it ourselves. Therefore, we can take over the task for adjustments after you’re done with it.
Does that work for you?

cc: @foalsboy

[abhinavrastogi-harness]

@3em webhooks can either have a "passed" or "failed" status. I don't think we need a "executing" status. We can use the field last_execution_result for that.

For the list page, can you please update the design and add the status in the view, similar to current design?

For point 3, we need entirely new screens. I'd again suggest that we should develop the views independent of the APIs. We can integrate functionality afterwards. This will ensure the views are indepenent of the specific API contracts.

[3em]

@abhinavrastogi-harness

For the list page, can you please update the design and add the status in the view, similar to current design?

The design team is already working on this, so we’ll be implementing it soon.

For point 3, we need entirely new screens. I'd again suggest that we should develop the views independent of the APIs. We can integrate functionality afterwards. This will ensure the views are indepenent of the specific API contracts.

Regarding this issue, okay, yes, we can go ahead and build the views, but it will involve extra data mapping for the components – which is acceptable.
However, if I’m not mistaken, this section already exists, meaning there’s already an API for fetching all the data, and you can provide it to us right away. Or is that not the case?

[abhinavrastogi-harness]

I confirmed with Rohan and Brad that Webhook Executions (point 3) is not in scope for the internal launch in Feb. I'd say we can wait on the designs for point 3, and let Rohan and @joetaylor-harness take a stab at coming up with a new UX for it.