What do you do after installation?

[hhdivil]

Followed your readme and installed the bridge without issues - but not quite sure what to do next!

Can you direct me to any other documentation on configuration?

Many thanks Dave

[ghost]

Haven't set it up, but it looks like you direct all requests to your mattermost server to this proxy (default port 5000) and configure it to forward to your mattermost server. I could be wrong.

Yes, needs some more docs

[zx1986]

Same question. After start the docker container, then add a Bitbucket repo's webhook like: http://my.bridge.server:5000

Then, .... how could I specify my Mattermost channel to send notify? MATTERMOST_HOOK=https://my.mattermost.server/hooks/ seems don't have any channle info?

[zx1986]

ok, I saw the source code: https://github.com/danielkappelle/bitbucket-mattermost-bridge/blob/master/bridge.py#L36

I think I should create a webhook on Bitbucket that like: http://my.bridge.server:5000/hooks/<my-mm-hook-hash>

Am I right?

[zx1986]

I thought that: https://github.com/danielkappelle/bitbucket-mattermost-bridge/blob/master/bridge.py#L67

add a channel will be better.

Sorry, bad idea, channel specify in URL params will be better.

[ghost]

I'm proxying mattermost through apache. My apache vhost config, relevant to mattermost, looks like this:

    ProxyPreserveHost On
    RewriteEngine On

    RewriteCond %{REQUEST_URI}  ^/api/v1/websocket     [NC,OR]
    RewriteCond %{HTTP:UPGRADE} ^WebSocket$            [NC,OR]
    RewriteCond %{HTTP:CONNECTION} ^Upgrade$           [NC]
    RewriteRule .* ws://127.0.0.1:8065%{REQUEST_URI}   [P,QSA,L]

    RewriteRule ^/bitbucket/(.*) http://127.0.0.1:8064/$1 [P,QSA]
    RequestHeader set X-Forwarded-Proto "https"

    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME}   !-f
    RewriteRule .* http://127.0.0.1:8065%{REQUEST_URI} [P,QSA,L]
    RequestHeader set X-Forwarded-Proto "https"

    <Location /api/v1/websocket>
        Require all granted
        ProxyPassReverse ws://127.0.0.1:8065/api/vi/websocket
        ProxyPassReverseCookieDomain 127.0.0.1 mattermost.foobar.com
    </Location>

    <Location />
        Require all granted
        ProxyPassReverse http://127.0.0.1:8065/
        ProxyPassReverseCookieDomain 127.0.0.1 mattermost.foobar.com
    </Location>

    LogFormat "%{X-Forwarded-For}i %l %u %t \"%r\" %>s %b" common_forwarded
    ErrorLog  /var/log/apache2/mattermost.foobar.log
    CustomLog /var/log/apache2/mattermost.foobar.log common_forwarded
    CustomLog /var/log/apache2/mattermost.foobar.log combined env=!dontlog
    CustomLog /var/log/apache2/mattermost.foobar.log combined

Please note the relevant part for handling requests from bitbucket:

    RewriteRule ^/bitbucket/(.*) http://127.0.0.1:8064/$1 [P,QSA]
    RequestHeader set X-Forwarded-Proto "https"

Per the above, I've decided to use port 8064 for this bridge to listen:

host = os.environ.get('BRIDGE_LISTEN_ADDR', '127.0.0.1')

# listening port, default 5000
port = os.environ.get('BRIDGE_LISTEN_POST', 8064)

# url to post bridged webhooks to
webhook_url = os.environ.get('MATTERMOST_HOOK', 'http://127.0.0.1:8065/hooks/')

I set up a new hook in mattermost, which generates a url with format: /hooks/[hook-id]. Before adding this URL as a bitbucket hook, I change the url by prepending /bitbucket to the URI, as follows: /bitbucket/hooks/[hook-id].

With this, the request from bitbucket comes into the web server (on port 443, handled by Apache). Apache detects a request to /bitbucket/hooks/?? and rewrite its to /hooks/?? and passes it along to the mattermost server, which is on port 8065. Internally, the bitbucket-mattermost-bridge is running on port 8064 which is reflected in both the apache config and my config.py for the bridge.

Thus, two general scenarios are handled:

[Normal Request, URI does not start with /bitbucket] 
    -> [Port 443, Apache] 
    -> [Port 8065, Mattermost]

[Bitbucket request, URI starts with /bitbucket] 
    -> [Port 443, Apache] 
    -> [Port 8064, bitbucket-mattermost-bridge] 
    -> [Port 8065, mattermost]

There are probably better ways; maybe I should have used a <Location> directive instead.

This should be enough for someone to get going. This functionality will be integrated into Mattermost sooner or later, anyway.

[ghost]

It occurred to me that it would be better to look for something in the header to identify that the request is a bitbucket hook. This way the URL that is generated by Mattermark can be added to bitbucket directly, without modification.

When bitbucket sends a request to your server, there's probably a header that identifies that the request is related to a bitbucket hook. Better to use that instead of changing the URI around.

[zx1986]

@gtcode good work. But it seems to complicate to me :-p

I got a Caddy server as a proxy:

mm.server.tw {
  proxy / backend.server.tw:8065 {
    websocket
    transparent
    header_upstream Host {host}
    header_upstream X-Real-IP {remote}
    header_upstream X-Forwarded-For {remote}
    header_upstream X-Forwarded-Proto {scheme}
  }
}

And as you can see, MM runs on backend.server.tw:8065 .

Then run the bridge on backend.server.tw with docker:

  mm-bridge:
    build: .
    container_name: mm-bridge
    restart: unless-stopped
    environment:
      - MATTERMOST_HOOK=https://mm.server.tw/hooks/
      - MATTERMOST_USERNAME=Bitbucket
      - BRIDGE_LISTEN_ADDR=0.0.0.0
      - BRIDGE_LISTEN_PORT=5000
    ports:
      - "5000:5000"

The last, setup a webhook on repo in Bitbucket: http://backend.server.tw:5000/hooks/<my-mm-webhook-hash>

If the <my-mm-webhook-hash> is mapping to the town-square channel in MM, then the setup repo's git push will notify in town-square channel.

But !!! If I have 10, more git repositories / channels, and I want to mapping each repo to each different channel, I have to generate 10 or more webhook in MM ..... then config each in Bitbucket repo .....

[ghost]

Yes, it might be easier to simply open up port 5000 on your server, and accept the request directly into the python bridge. Still need to customize the URL given by Mattermost before adding it to bitbucket. It's just that I prefer to have a single port open, with TLS encryption handled by a proper web server.

In a production environment you will probably want to have, at least, a web server proxying the requests anyway. That's why I jumped through some small hurdles to unify everything in Apache.

In any case, the bridge itself is a work-around anyway. Any techniques described here are temporary. It's only a matter of time before Mattermost integrates this type of functionality.

[zx1986]

It's only a matter of time before Mattermost integrates this type of functionality.

That's true :-(