Add webhook automation rules for builds

[humitos]

Initial and minimal implementation for webhook filtering rules:

Peek.2026-02-02.14-33.webm

The pattern is not polished or anything similar. I just add the pieces required to be able to "have something in the UI" and be able to test it without using DJango shell. That's all for now.

Required by readthedocs/readthedocs.org#12697

[agjohnson]

I would not use two buttons here. This should either be a dropdown at least. Better yet the type selection should be part of the create form. The distinction between version rule and push rule is not clear.

To keep this just for testing, I'd add a feature flag to control the UI.

[ericholscher]

I really don't like the pattern we have with so many drop downs -- it makes every action require +1 clicks. Every time I have to configure a project it annoys me that I have to click a dropdown with 1 item in order to click the item in it. We should really be trying to keep the number of clicks to a minimum, and a 2-item dropdown feels like much worse UX than 2 buttons?

[humitos]

Better yet the type selection should be part of the create form.

I didn't want to start in that direction because I'm not sure how easy it will be to explain these differences. Starting with a different UI is easier for now while we have all the other conversations around this feature.

I'm arriving at the conclusion we will end up with two different set of automation rules:

• The ones that are applied to branches/tags/versions (Version Automation Rules) with multiple actions (active, de-active, etc)
• The ones that are applied to webhook data (Webhook Automation Rules) with only one action for now (trigger a build)

These look simpler to communicate and understand where the filter/action is applied to.

To keep this just for testing, I'd add a feature flag to control the UI.

Makes sense 👍🏼

[humitos]

Every time I have to configure a project it annoys me that I have to click a dropdown with 1 item in order to click the item in it

I have the same bad UX here. I usually click on the project and then click on the settings. Those links are a lot bigger and easier to click than a small three dots square and another small button under the dropdown.

We should really be trying to keep the number of clicks to a minimum, and a 2-item dropdown feels like much worse UX than 2 buttons?

Agree 👍🏼

---

I'm interested in having this conversation, but I would like to not have this conversation here in this PR. I'd appreciate if we move it outside it 😄

[ericholscher]

I'm interested in having this conversation, but I would like to not have this conversation here in this PR. I'd appreciate if we move it outside it 😄

Cool, we can continue here: #694 :)

[ericholscher]

I'm arriving at the conclusion we will end up with two different set of automation rules:

• The ones that are applied to branches/tags/versions (Version Automation Rules) with multiple actions (active, de-active, etc)
• The ones that are applied to webhook data (Webhook Automation Rules) with only one action for now (trigger a build)

These look simpler to communicate and understand where the filter/action is applied to.

This makes sense to me to start. But it's definitely a larger change that we should think more about how to explain to users. I feel like we keep adding additional complexity to these UIs (eg. Redirect Types) that make it way more complicated for users, and I wonder if we can expose simpler abstractions to users that hides some of the complexity.

[agjohnson]

I'm arriving at the conclusion we will end up with two different set of automation rules:

Hrm I'd like to know why you're finding this is the case.

I haven't jumped into what it would take but it feels like with a more complex form, or two separate form classes, we should be able to provide a pretty dynamic create/edit form that covers everything.

I really would like to avoid separating these at all possible costs. This might take experimentation on the UI side and doesn't need to happen immediately. But should be at least in the plan so we're not unraveling things later.

simpler abstractions to users that hides some of the complexity.

The thing I notice working with forms is that the UX tends to be very bare minimum when we implement forms. I don't know I'd replace the pattern with a different abstraction. The user would benefit from have as simple a form as possible though, but this will take some attention to detail with customizing the form and widgets.

We should really be trying to keep the number of clicks to a minimum

I don't disagree wholly about less clicks, but focusing on clicks not the correct framing here. Grouping tasks visually and reducing noise and slop in the UI is about giving the user as few distractions and bad visual guidance as possible. When a user is unsure about our UI, bad clicks cost way more than having to click an extra dropdown periodically.

Here, I don't want two buttons because the user shouldn't have to know the difference between the two options before they click one of the add buttons. A dropdown is pretty standard UI, gives more chance to guide the user, and really is not going to be what stops a user from using this feature.

The project listing is only a context menu because it had more items in the context menu previously, it can be squashed or we add more items in the menu. But that is very separate from this.

[humitos]

OK, I updated this PR to only show "the new button" to superusers. That way, we can start testing this by ourself either using the Django console or the minimal UI I've created.