Hi,
I'm trying to integrate GitHub push events by using Incoming webhooks.
But, unfortunately, I had no luck.
From source code (platform/web/web.go), incoming webhooks requires "text" field in webhook payload,
OTOH, GitHub PushEvent, which described here:
https://developer.github.com/v3/activity/events/types/#pushevent
does not have "text" field.
So, Mattermost replies the following error message to GitHub.
[EROR] /hooks/xxx-key-xxx code=500 ... No text specified [details: ]
Does Incoming webhooks not support GitHub (or GitLab or GitBucket) webhooks yet?
or
Do you have any plan to support this?
Thanks
GitLab notifications to Mattermost via the Slack UI are confirmed to work and documentation for setup is available.
The GitHub payload looks pretty different.
There are multiple integrations for GitHub and Mattermost and each formats the Mattermost post differently.
Would anyone be interested in making a PR to better support how Mattermost's incoming webhooks handle raw data from GitHub's raw webhook integration?
For now the extra handling could be hardcoded, eventually we'd probably want to expose some sort of plug-in format to add more of these.
Thanks for your reply!
My workaround was very similar to the softdevteam/mattermost-github-integration,
but this project seems to be more powerful than mine. I'll try it.
Slack - GitHub integration is very popular, so many user needs this feature, I think.
I wish that Mattermost's incoming webhooks support GitHub's raw webhook.
Thanks
It's an interesting idea, to interpret the payload of a generic webhook we'd probably need to create a "type" system for webhooks.
Would anyone in the community be interested in working on this?
FYI,
I found hubot-mattermost is another altenative to integrate mattermost) and GitHub (GitBucket/GitLab)
e.g.) GitHub --(webhooks)--> Hubot --(hubot-mattermost)--> Mattermost
Now, I'm trying this.
Thanks @iwaseyusuke, closing this ticket since the original issue seems to be answered,
So from mattermost persepctive this "bug" is wont-fix and suggested solution is to run yet another bot ?
Wouldnt it make more sense to have the webhook type derived from senders user-agent so it github webhooks could work out of box ?
I'm on the same boat with you. Did anyone have a solution for this ?
Most helpful comment
So from mattermost persepctive this "bug" is wont-fix and suggested solution is to run yet another bot ?
Wouldnt it make more sense to have the webhook type derived from senders user-agent so it github webhooks could work out of box ?