Add webhook support for Bitbucket and GitLab

[swissspidy]

Although the plugin now theoretically supports fetching projects from Bitbucket and GitLab.com, we don't support receiving webhooks from these providers just yet.

Without that support, the plugin isn't that useful when on these platforms.

Right now we add a custom github-webhook/v1/push-event REST route for consuming incoming GitHub webhooks. This has two big disadvantages:

• The name is not really uniquely namespaced.
• The REST callback is very GitHub-specific, e.g. by checking for X-GitHub-Event headers and assuming a certain data structure.

Possible solutions:

• Add a new traduttore/v1/<provider>-incoming REST route for each provider. Examples:
  • traduttore/v1/github-incoming
  • traduttore/v1/bitbucket-incoming
  • traduttore/v1/gitlab-incoming
  • traduttore/v1/custom-incoming (common route for custom repositories with filterable callback)
• Deprecate github-webhook/v1/push-event in favor of traduttore/v1/github-incoming
  Migration might be easier with something like Create GitHub App / Bot / Integration #55
• Alternatively: use only one REST route, e.g. traduttore/v1/incoming-webhook and choose correct handler depending on source. This could be a separate class per source.
  The question here would be how the source could be detected in a reliable matter.

---

Bitbucket documentation:

https://confluence.atlassian.com/bitbucket/manage-webhooks-735643732.html
https://confluence.atlassian.com/bitbucket/event-payloads-740262817.html

GitLab documentation:

https://docs.gitlab.com/ee/user/project/integrations/webhooks.html

[swissspidy]

Looks like this is the only issue left in the 3.0.0 milestone.

@ocean90 @grappler What do you think of a single traduttore/v1/incoming-webhook route? This way we wouldn't pollute the REST API with a bunch of very similar routes.

[ocean90]

Sounds good to me.