Gitea: Custom Webhook Templates

[bkcsoft]

Description

We should allow for custom webhooks. And while we're at it, migrate current webhooks into the new format (This is make it easy for people to remove slack-support (or rename to Mattermost) link to issue ).

I see this being interated in 5 steps (maybe less depending on size of PRs)

1. Add a new webhook-type for custom payloads, this one reads {name}_payload.tmpl and logo {name}.png from options/webhooks/ and custom/webhooks/.
2. Add UI for actually enabling them :trollface:
3. Support for "Metadata", as in Name, and custom fields (for config-page). Should be in a file...
   Could also add support for URL-based icon (to reuse gitea-logo)
4. Support for sending custom Headers
5. Migrates all existing Slack & Gitea webhooks to the new format 🎉

The way I see it we'd end up with this:

/options/webhooks/
                 /gitea.png
                 /gitea_payload.tmpl
                 /gitea_headers.tmpl
                 /gitea_metadata.yml
                 /slack.png
                 /slack_payload.tmpl
                 /slack_headers.tmpl
                 /slack_metadata.yml
/custom/webhooks/
                /foobar.png
                /foobar_payload.tmpl
                /foobar_headers.tmpl
                /foobar_metadata.yml

Screenshots

_Will try to make mockup screenshots_

[lunny]

How to resolve multiple languages issue?

[bkcsoft]

Multiple language issue? You mean for the list? Do they need to be localized? AFAIK "Slack" would be "Slack" in all languages no?

[lunny]

OK. They still could customize their locale files.

[bkcsoft]

The best part about having webhooks be templates, is that the templates would provide its own translations. So for any built-in templates Gitea provides, we would have separate translation-files for them in Crowd-In :slightly_smiling_face:

[pinpox]

Any updates on this? I'd offer to help and submit a PR if someone can guide me a bit. Haven't hacked much on gitea yet, but really would like to use this feature

[lunny]

You could save all the webhook messages on template files and then read and execute template before send webhooks.

[alexanderadam]

This feature would solve a bunch of issues at once (i.e. #2139, #5252, #5267, #5496, #5548, #7488, #7548, #7788, #7973, #8473, #8963, #9000, #9134, #9485, #9504, #9746, #10288, #10418, #10719, #12712, #13063).

But what's more important: the maintenance probably becomes _easier_ because people could simply add PRs for the _templates_ (or have local custom ones) instead of having a growing hard coded list of webhook services that live in the Go source.

PS: Webhooks that doesn't come with an HTTP interface (i.e. #7549 or #5469) won't be solved by this naturally.

[guillep2k]

PS: Webhooks that doesn't come with an HTTP interface (i.e. #7549 or #5469) won't be solved by this naturally.

We could allow the use of external commands for that, like we do for external renderers. That would cover a lot of ground.

[alexanderadam]

We could allow the use of external commands for that, like we do for external renderers. That would cover a lot of ground

Absolutely! That makes sense. I guess via template / GUI as well?
Something like

$ command $project $commit_hash $prev_commit_hash $project_tags static_param foo

would be nice.

[tacotexmex]

Badly needed for my Matrix integration going forward.

[lunny]

@guillep2k @alexanderadam But this has been implemented via git hooks? You can edit git hooks on repository settings UI.

[alexanderadam]

But this has been implemented via git hooks? You can edit git hooks on repository settings UI.

You are just referring on the external command integration, right?
That's true, I didn't think of that. Thank you!
The major topic of this issue is still open however. :wink:

[guillep2k]

@guillep2k @alexanderadam But this has been implemented via git hooks? You can edit git hooks on repository settings UI.

@lunny I don't know about that. AFAIU git hooks will run under Gitea's user, so they are only available to the site admin or selected users? What I was thinking was something any repo owner can chose from a closed-list, pre-defined by the admin in custom/otherhooks like we do with labels or gitignore.

[fawdlstty]

How are the plans for this feature going?

[WattsC-90]

this is a great feature if it can come in soon! want to integrate gitea with existing issue management tool without having to write a custom service in the middle to swap from one to the other! :)

[lunny]

Different events should have different templates, so we can define a yml with multiple sections.

/options/webhooks/
                 /gitea/logo.png
                 /gitea/payload.yml
/custom/webhooks/
                /foobar/logo.png
                /foobar/payload.yml

name: gitea
headers:
metadata:
    channel: {{.Channel}}
events:
    create: 
        title: The {{refType}} {{refName}} has been created.
    deleted:
        title: ssssss
       ......