It's probably NOT that you're incompatible.
In my case, the difficulty of getting this working comes from me not initially understanding all that is going on:
I am using mattermost as part of a gitlab "omnibus" installation, and understanding what the "omnibus" thing is doing as it updates and manages things (with chef, I believe) leads to some confusion at times.
The mattermost documentation refers to things that don't exist like some /opt/mattermost/bin/platform executable. The name of the executable (platform) is is a stupid historical accident and like all stupid historical accidents is not worthy of mention anywhere in any documentation, and so it's a stumbling block for new users who are not even expecting to learn mattermost (they are just gitlab users). In the omnibus repackage of the mattermost binaries, they did a sensible rename to actually name the main mattermost binary to mattermost.
Database schema upgrades have of late proved an extreme source of pain since the mattermost omnibus chef recipes are trying to automate a bunch of (I believe) postgres SQL schema change updates during updates. These are failing routinely on me, between 7.x and 8.x updates. Even fresh installs of Gitlab Omnibus followed by enabling Mattermost in gitlab.rb were not working on a fresh clean VM out of the box for me as recently as June 2016. I may need to retry that clean VM test now that gitlab 8.9.5 CE is released.
Troubleshooting tools provided with the gitlab+mattermost are sorely lacking. Also any notes on how to manually start up mattermost are sorely lacking. When I determine a useful shell hack, I have a pattern of making a shell script for that purpose. I have built up quite a little library of mattermost and gitlab shell scripts that I use to diagnose things when things go pear shaped.
here's one I recommend to everyone: I have this as /root/gitlab-mattermost
When mattermost is not runnable (because Go panic, a Panic is Go's uber-shitty and opinionated replacement for exceptions), it helps to run it from your root shell, while impersonating (with sudo -u mattermost) the correct user account so you can see it panic, or so you can run some command like -upgrade_db_30.
#!/bin/sh
cd /opt/gitlab/embedded/service/mattermost
sudo -u mattermost /opt/gitlab/embedded/bin/mattermost -config=/var/opt/gitlab/mattermost/config_alt.json $@Usage examples:
/root/gitlab-mattermost -version
/root/gitlab-mattermost -help
There, I invoked mattermost and if I got a version output then mattermost's Go codebase is not in a pissy mood, and feels like running without panicking.
It may be pissy about localization and just dump core when you try to run it, or anything else. If it is, you have to figure out how to fix the gitlab-mattermost binary or its supporting files. When it's in a mood like that, obvious your gitlab and mattermost integration is NOT working.
Note also that mattermost is pissy about what the current directory is, and that's why my shell script above forces a current working directory before running the command line command. Instead of saying "hmm, maybe you're in the wrong directory" when you run the mattermost binary, it's going to panic with some irrelevant message about english localization files not being found. Nice.
W