-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Custom Webhook Templates #1089
Comments
How to resolve multiple languages issue? |
Multiple language issue? You mean for the list? Do they need to be localized? AFAIK "Slack" would be "Slack" in all languages no? |
OK. They still could customize their locale files. |
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 🙂 |
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 |
You could save all the webhook messages on template files and then read and execute template before send webhooks. |
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, #13592). 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. |
Absolutely! That makes sense. I guess via template / GUI as well? $ command $project $commit_hash $prev_commit_hash $project_tags static_param foo would be nice. |
Badly needed for my Matrix integration going forward. |
@guillep2k @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? |
@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 |
@jolheiser le me reply here to #19307 (comment), since this seems a better place to discuss about it As far as I understand, it seems already agreed that gitea should offer a way for instance administrators to offer "custom webhook templates". Looking at the current implementation and the issues for new webhook, it seems that what is actually needed is the possibility to "shape" the canonical JSON along some metadata to adapt to the different services. For instance matrix, Slack and telegram output a smaller JSON with a "text" field summarizing the changes. So it seems that what is needed is way to transform a JSON document into another JSON document at runtime. The current implementation is in Go, so it doesn't allow customization at runtime (requires a new compilation). This issue mentions "templates" and #1089 (comment) showed a In #19307 (comment) I propose bloblang, which is a document mapper, written in Go. It could read some "mapping" files and run them before delivering the payload.
Cons:
Another possibility would be javascript #19307 (comment) proposed https://github.com/dop251/goja
Cons:
What do you think of this overview? |
(if |
I agree that describing payloads in YAML is going to be a horrible UX, which is why my current WIP PR didn't go that route. The current implementation of that PR essentially allows defining a limited UI and passing the payload+form data to another bridge service. More or less a normal Gitea webhook + some limited form data. As noted in that same PR, some other maintainers want to have it all in the DB, which has stalled the PR because I also think that's bad UX. Regarding It seems there are conflicting opinions on the very basics of how this should work currently. My original PR included the ability to run custom scripts rather than requiring another running service, but it was scrapped in favor of bridge services (even though those are currently possible and yet not widely used) In order to continue this, I think we need to get a clear answer on what is going to be allowed before we begin to discuss implementations.
To answer the above with my own opinions:
|
I would say yes. The goal of a webhook is to communicate with another service, very unlikely running on the same machine. If you can control what runs on the machine, then exposing a service via a local port is not hard to do (however this is only accessible to instance administrators, which represent a minority of the gitea users).
I don't understand what you mean. If I want to post a message to mattermost/matrix/discord every time a PR is opened, I only need to shape the payload (and add some Authorization headers). If the "custom webhook" allows this, I don't need a bridge. The usecase I actually want to do, is trigger a sourcehut build.
I would restrict "people" to "gitea-dev" and "instance-administrator". Another possibility would be wasm.
I think that it should be a language restricted enough (I fear, that if JS is allowed, the "people" will expect to be able to perform "fetch" requests directly from the script - which could be interesting, but not really a "webhook" anymore, more like a "hook").
Actually I think we should take a step back and ask who should be allowed to customize what for the webhooks. Currently:
What workflows do we want to allow/ease? Here is my take:
I would refrain (at least for now) to allow the end-user to create a custom webhook. so I agree with @jolheiser that the config files/images should live on disk (I do agree with you on something 🤗 :) |
@oliverpool Are you on Discord or Matrix by chance? I think perhaps it may be more effective to line up there and then post a summary here once we've aligned our thoughts. |
Thinking more about this the {
"payload":{
"hash": "123456",
"message": "en event happened"
},
"content_type": "application/json"
// other keys can be added later. "headers" for instance
} |
For those who can't wait for this one to become ready and merged like me (#19307) that would like to use Gitea Webhooks with Google Chat in the meanwhile, then I'd like to share with you that I've found a good workaround using a NodeJS proxy in a docker container that translates slack webhooks to google chat webhooks. It's working fine for me :) |
@jolheiser I recently looked at the webhook state and to allow moving forward, I would recommend splitting this issue in 2 steps:
Currently to generate a webhook request, the following happens:
I think a couple of things could be refactored: 2.
|
I would need to refresh myself a bit on the webhook code, but that sounds feasible at a glance. I've been meaning to get back to this, but my TODO list never seems to decrease. 😔 |
Does Gitea Webhook currently not support docking with argo events? |
@jolheiser (and anyone following here on this issue) I drafted a refactoring of the webhook_task database storage (proposed in #1089 (comment)) on codeberg: https://codeberg.org/forgejo/forgejo/pulls/2231 I plan to upstream this to gitea when this draft is complete. I look forward to any feedback! (here, on matrix or on codeberg) |
I still think we need a table to save the customized |
@lunny my PR does not implement any customized HookType. It is more of a step to simplify the hook interface, so that adding custom types (in later PRs) should be easier. |
I mean the migrations is unnecessary, we can put them into the |
You are right, the impact of the migration must be checked, I will ask codeberg to run it on a copy of the database (it can likely be make faster by using parallelism). I think that this migration is worthwhile, because it enables a substantial cleanup of the webhook code. Defining a new webhook inside gitea (as Go files) will touch far fewer files after this PR (for instance the matrix hook currently has some logic inside the The proposed PR is more of an intermediary step:
|
@lunny after considering the feedback that I received (inclusive yours, thank you for it!), I am proposing another approach: https://codeberg.org/forgejo/forgejo/pulls/2263 (saving the raw event as-is and doing the type-dependent logic right before sending). With this new approach, the migration is much lighter (only adding a |
@lunny regarding the specific logic added in gitea/modules/webhook/payloader.go Lines 37 to 42 in b51bd7f
Do you know if this old (June 2020) comment of yours is still up-to-date? #11940 (comment)
Looking at the current code:
So I guess that this can be simplified to: case models.HookEventIssueComment, models.HookEventPullRequestComment:
return s.IssueComment(p.(*api.IssueCommentPayload)) What do you think? |
@jolheiser I have a branch ready, for which I plan to open a PR here soon: https://codeberg.org/forgejo/forgejo/pulls/2263 Following the discussion with @lunny and other feedback, instead of saving the request to be delivered in the database, it saves the raw event and creates the webhook-dependent request right before delivering it. Hence the webhook-specific logic is exists within Feel free to comment on codeberg, or wait for the PR here. |
PR has been opened here: #29145 |
Now that #29145 has been merged, is there a logical path forward for this? |
I would have thought custom would've been the first type to be supported because using variable replacement and a template you could support so very many right away... |
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)
{name}_payload.tmpl
and logo{name}.png
fromoptions/webhooks/
andcustom/webhooks/
.Name
, and custom fields (for config-page). Should be in a file...Could also add support for URL-based icon (to reuse gitea-logo)
The way I see it we'd end up with this:
Screenshots
Will try to make mockup screenshots
The text was updated successfully, but these errors were encountered: