Can't filter webhooks of Pull Requests #6362

New Issue

GiteaMirror · 2025-11-02T06:53:36-06:00

GiteaMirror commented

2025-11-02 06:53:36 -06:00

Originally created by @lhemala on GitHub (Nov 20, 2020).

Gitea version (or commit ref): 12.3

Description

Hi,
I noticed that getPayloadBranch doesn't work/returns an empty string when the api.Payloader is of type *api.PullRequestPayload.
Because of that I can't filter pull request related notifications (open/edit/reject/approve/merge) and send them to different channel in our slack

I fixed that issue in the following commit by using the head branch as relevant branch for the filter
d78e63a342

Before I open a PR I wanted to know if this functionality was left out intentionally, maybe because a PR has two branches to which the filter can be applied to (head and base) and therefore the filter might be ambiguous.

In my implementation I only filter for the head branch. If we'd want to filter for both the change would get bigger since the filtering logic only expects a single branch. (But still very much doable)

Relates to:
Enhancements of webhooks (#3998)
WebHooks: branch filter for push/pull request notifications (#2025)

Originally created by @lhemala on GitHub (Nov 20, 2020). - Gitea version (or commit ref): 12.3 ## Description Hi, I noticed that `getPayloadBranch` doesn't work/returns an empty string when the `api.Payloader` is of type `*api.PullRequestPayload`. Because of that I can't filter pull request related notifications (open/edit/reject/approve/merge) and send them to different channel in our slack I fixed that issue in the following commit by using the head branch as relevant branch for the filter https://github.com/lhemala/gitea/commit/d78e63a342b0c6a1e49fd40516fc12c251bd7b72 Before I open a PR I wanted to know if this functionality was left out intentionally, maybe because a PR has two branches to which the filter can be applied to (head and base) and therefore the filter might be ambiguous. In my implementation I only filter for the head branch. If we'd want to filter for both the change would get bigger since the filtering logic only expects a single branch. (But still very much doable) Relates to: Enhancements of webhooks (#3998) WebHooks: branch filter for push/pull request notifications (#2025)

GiteaMirror added the type/proposal label 2025-11-02 06:53:36 -06:00

GiteaMirror closed this issue

2025-11-02 06:53:36 -06:00

GiteaMirror commented

2025-11-02 06:53:36 -06:00

@6543 commented on GitHub (Nov 24, 2020):

you can not filter webhook in UI, API, ?!?

@6543 commented on GitHub (Nov 24, 2020): you can not filter webhook in UI, API, ?!?

GiteaMirror commented

2025-11-02 06:53:37 -06:00

@lhemala commented on GitHub (Nov 25, 2020):

not for webhooks origination from actions on a pull request (PR open/PR edit/PR reject/PR approve) as I wrote above

@lhemala commented on GitHub (Nov 25, 2020): not for webhooks origination from actions on a pull request (PR open/PR edit/PR reject/PR approve) as I wrote above

GiteaMirror commented

2025-11-02 06:53:37 -06:00

@lhemala commented on GitHub (Nov 25, 2020):

Let me elaborate the use case:
We have a monorepo which includes, among other things, our front and backend. In our Slack we have two separate channel on which the respective devs always keep an eye on.
We set up two Slack webhooks in Gitea (via the GUI). One has fe/** as filter, the other be/**, which matches the names of our branches and PRs.

Without the patch, both webhooks fire for any newly opened/edited/approved/rejected PR. With the fix I propose this is not the case and our devs only find the messages they are interested in their respective channel.

@lhemala commented on GitHub (Nov 25, 2020): Let me elaborate the use case: We have a monorepo which includes, among other things, our front and backend. In our Slack we have two separate channel on which the respective devs always keep an eye on. We set up two Slack webhooks in Gitea (via the GUI). One has `fe/**` as filter, the other `be/**`, which matches the names of our branches and PRs. Without the patch, both webhooks fire for any newly opened/edited/approved/rejected PR. With the fix I propose this is not the case and our devs only find the messages they are interested in their respective channel.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/gitea#6362