Add support for Bark webhook integration

[ZeroDeng01]

This commit introduces the Bark notification integration, allowing users to configure Bark webhooks in repositories. It includes form models, templates, routing changes, and test cases to handle Bark webhook functionality.

Close #35717

[GiteaBot]

@ZeroDeng01 I noticed you've updated the locales for non-English languages. These will be overwritten during the sync from our translation tool Crowdin. If you'd like to contribute your translations, please visit https://crowdin.com/project/gitea. Please revert the changes done on these files. 🍵

[lunny]

Sorry, I don't think we should accept too many webhook types.

[ZeroDeng01]

Sorry, I don't think we should accept too many webhook types.

Yes, too many webhooks can indeed seem bloated, but as an individual user using Gitea as a Git repository and CD/CI platform, a lightweight webhook notification channel and tool is needed, including but not limited to better alternatives like Bark.

[wxiaoguang]

It depends on the popularity. There are so many (at least dozens of or maybe hundreds or thousands of) notification systems. If every webhook is maintainable, then it's good to have native support. But the challenge is that there is no manpower to maintain so many webhook systems.

And I also would like to say that it's a shame that Gitea side made no progress of making supporting custom webhook eaiser for years.

---

For your requirement, maybe a separate webhook proxy server works better: Gitea uses Gitea's webhook to send notifications to your webhook proxy, and the webhook proxy can forward the notification to your systems.

[ZeroDeng01]

It depends on the popularity. There are so many (at least dozens of or maybe hundreds or thousands of) notification systems. If every webhook is maintainable, then it's good to have native support. But the challenge is that there is no manpower to maintain so many webhook systems.

And I also would like to say that it's a shame that Gitea side made no progress of making supporting custom webhook eaiser for years.

---

For your requirement, maybe a separate webhook proxy server works better: Gitea uses Gitea's webhook to send notifications to your webhook proxy, and the webhook proxy can forward the notification to your systems.

Yes, maintaining a large number of webhooks categories is indeed a disaster for open source projects! At present, the API protocol of Bark has been stable for many years. The standard API has hardly been updated since its release. This is one of the reasons why I have chosen Bark for many years. I believe other users have similar ideas!

It would be great if Gitea had a more powerful custom webhook system! Perhaps we could consider defining the messages for different Gitea events as variables, so that users can define different message formats using variable placeholders. Regarding authentication and authorization, we could support the usual HTTP API methods, such as injecting authorization tokens through headers!

---



However, at this stage, there is an urgent need for a lightweight webhook notification solution that does not rely on deployment or development of third-party proxy services!


[silverwind]

Didn't we have a "generic" webhook type? I think the "gitea" one might be it. I think long term it would be best to remove all custom webhook types and make one generic type work for them all (e.g. completely removing the type option), like GitHub also only has one webhook type.

I don't mind adding another webhook type now, but the sooner we can get them into a generic type, the better.

[ZeroDeng01]

Didn't we have a "generic" webhook type? I think the "gitea" one might be it. I think long term it would be best to remove all custom webhook types and make one generic type work for them all (e.g. completely removing the type option), like GitHub also only has one webhook type.

I don't mind adding another webhook type now, but the sooner we can get them into a generic type, the better.

It seems unreasonable to keep only one webhook type in the current stage. Since Gitea's webhooks are not flexible enough to configure, many general-purpose systems would require code development to integrate with webhooks. If Gitea had a powerful webhooks system, keeping only one type would be perfectly fine. Before a reasonable custom webhooks system is developed, we can still choose to independently integrate various systems using the native approach.

---

About a Universal Webhook System

I think a universal webhooks system needs to be able to flexibly customize the payload format. GitLab does this well with its Webhook Template feature (see documentation: https://gitlab.cn/docs/jh/user/project/integrations/webhooks/#example-custom-webhook-template). Users can use this feature, combined with system variables, to define their own JSON data format and content. In most cases, users can adapt to the integration needs of different third-party systems by modifying different JSON formats. For example, DingTalk and WeChat Work are enterprise IM systems widely used by Chinese users. Many development teams need to receive relevant push notifications in their groups. At this point, a flexible JSON data format becomes particularly important (although a custom payload is not as perfect as native integration, it is still usable).

[silverwind]

Looks reasonable

[wxiaoguang]

But it is iOS only (Bark is an iOS App)? Can there be something more general for whole ecosystem?

[silverwind]

I think a universal webhooks system needs to be able to flexibly customize the payload format. GitLab does this well with its Webhook Template feature

Yes, we definitely need a small template system for webhook payloads, e.g. present the user a textarea/monaco editor with the json payload and let them interpolate a few pre-defined variables into it. It does not sound too hard to do.

[ZeroDeng01]

But it is iOS only (Bark is an iOS App)? Can there be something more general for whole ecosystem?

Yes, Bark currently only offers iOS support, thanks to iOS's excellent APNs messaging service. However, Android currently lacks a unified push service! If a good Android client for webhook messaging is developed, I'd consider integrating it later (until Gitea has a good payload template feature or something similar, I think this maintenance is necessary).

---

ServerChan currently supports push messaging on multiple platforms (WeChat, Bark, PushDeer, etc.), but this is a commercial project, so I haven't proposed it yet.

[TheFox0x7]

Yes, we definitely need a small template system for webhook payloads, e.g. present the user a textarea/monaco editor with the json payload and let them interpolate a few pre-defined variables into it. It does not sound too hard to do.

I was thinking we could use jsonnet for this actually. We'd get templating and could just prepare and the event metadata then let user create the actual payload they want, plus we don't have to worry about json being valid or not. It might be overkill for this though...

Android currently lacks a unified push service!

Does it? Isn't FCM the facto standard there?

[ZeroDeng01]

Does it? Isn't FCM the facto standard there?

Yes, but FCM does not work well in some regions, such as CN. Due to FCM, almost every mobile phone manufacturer in CN has its own message push standard, which makes it difficult to implement Android in some regions to push messages without relying on background resident.

[silverwind]

I was thinking we could use jsonnet for this actually.

I would just do handlebars / go template inspired syntax with double braces (which can not occur in json like that):

{
  "username": "{{username}}"
}

[nemoinho]

Hey there,

after coming back to gitea after a few years of absence I was actually very confused to see all the options to simply define a webhook. Especially that the simple default hook is called "gitea" (I was expecting something like "default" or "generic").

In my opinion the project should definitely stop adding any more hook types. Instead, focus on a simplification of the hook-system and then handle them more generic, please.

I mean github as the biggest platform of this kind is very minimalistic and it works well, same for the Chinese copy gitee and many others...

We have to support all the already existing hooks in a way, though. Therefore, I would start with these requirements:

• Define a target-URL
• Define a HTTP-Method (default: POST)
• Content-Type (default: application/json)
• Authentication-Header (optional)
• List of trigger-events (default: push)
• A secret to detect spoofing-attempts and other malicious requests (see: Validating webhook deliveries)
• A user-defined payload (optional)

As far as I understand the current integrations this would be sufficient to address them all. Even this new one for bark.

In a second step we could add a kind of template system to the user-payload and all kinds of other features, like an editor.

Finally, we could add a wizard to the administration-panel to configure custom integrations per instance. This would then allow us to define custom input fields and map them to a payload and configure some meta attributes (thumb-nail, name, description, etc.). This could even be configured in the app.ini, so it doesn't have to be configured by hand!

I agree that this approach is less sexy and fast, but it is very versatile and removes all the pressure of integrating all kinds of services and tools as "webhooks". Instead we could provide some good documentation and call it done.

With such a roadmap we would ease the development and the use-cases, especially for those who need a custom integration like here with bark and those who only need a small subset of the already existing integrations.

Note, that with the wizard we could also keep both worlds intact, the current set of integrations and a clean sheet with custom setups!