what?#
this proposal adds support for webhooks to notify clients of git events. this can include events such as:
- branch / tag:
- pushed
- deleted
- pull:
- created
- resubmitted
- merged
- closed
- pull_comment:
- created
- issue:
- created
- closed
- issue_comment:
- created
why?#
i badly want to implement a ci system to move my projects to tangled.
that aside, this will allow for implementing clients that react to these events for usecases like:
- ci pipelines
- auto-deployments
- bots for labelling, review, automerge, auto-close, etc.
how?#
- creating webhook:: a webhook section in repo settings page to add the url and events. these will be saved in the knotserver database.
- triggering webhook:: when a git event occurs, knotserver will trigger the webhooks saved in the database directly. for other events like pull creation, pull comment, etc, the appview will send an api call to the knotserver to trigger the webhook.
why trigger webhooks from the knotserver?
knotserver seems like the right place to trigger these webhooks from, since only it has access to the git events like branch creation, push, etc. also logically, knotserver seems like the right place to trigger the webhook, since it is the one hosting the git repo and it is expected to deal with the git events.
i think we should start with the core git events like branch push, tag push, etc. which would be the most impactful and useful for clients like ci servers.
let me know if this is something we would like to implement. i'd be happy to write up a more concrete spec and pr for this.