This is a fork of the original
It includes a custom config file specific to one implementation, but this can easily be modified in a new fork.
Heroku is a platform for easily deploying applications.
A buildpack provides framework and runtime support for apps running on platforms like Heroku.
An inline buildpack is a special buildpack that includes code for both the app and the buildpack that runs the app.
Matterbridge is a simple bridge that can relay messages between a number of different chat services, essentially connecting separate chat tools.
This fork is intended to help bridge channels between both the EDGI and Archivers Slack teams.
MATTERBRIDGE_URL. Use this to download the binary from a custom url instead of the tagged release from the official GitHub repo. (Setting this makes
DEBUG. Set to "1" to log all message events across bridges.
edgibranch to our heroku app:
edgibranch is protected branch, and changes must go through pull request process.
As a summary, this repo's configuration does some specific things for the g0v chat ecosystem:
g0v/slack-irc-pluginin the past, is now provided by this service. tool, using these parts of config. Some notes:
g0v-bridge, as it might later be used for relaying Telegram messages too.
hacklabto-bridgeas it was originally created for another team's gateway. No one will see this name in UI.
slack-irc-pluginseems to already allow, but there is an issue for implementing spoofing
Matterbridge uses Viper, and so each value in the TOML configuration can be set by envvar.
Basically, here are the rules:
So for example, with this in your TOML config:
You could instead set an environment variable for
MATTERBRIDGE_SLACK_G0V_TW_TOKEN and leave that key out of in the
configuration file template.
Matterbridge uses API endpoints for some things, like the API bridge and webhooks. In order to bind to a port and serve HTTP pages, the app must be run as a "web" dyno. If there is no need for HTTP endpoints (ie. no API nor incoming webhook access) then the app can be run as a "worker" dyno. The catch of using a web dyno is that it will fall asleep after 30 minutes of no incoming requests. This is bad if we're depending on this bridge to be running all the time.
To get around this, we can enable Heroku's "scheduler" add-on service. It is essentially like cron. We will set it up to hit our own app every 10 minutes, therefore keeping it from sleeping. If you have the Heroku CLI installed, you can enable this like so, from your project repo:
heroku addons:create scheduler heroku addons:open scheduler
If you don't have Heroku CLI, you will need to configure this manually from the Heroku website.
Now, using the web interface, create a task to run this command every 10 minutes:
curl --silent --head https://MY-APP-NAME.herokuapp.com/api/ping > /dev/null
Now that you're ready to keep the app awake, just switch over from using
the "worker" dyno to using the "web" dyno. (Both are defined in the
# Via Heroku CLI: heroku ps:scale worker=0 web=1 # Without Heroku CLI, do it from the Heroku web interface
Ok, now you're all set to go! But be WARNED, Heroku only gives out enough free hours to allow a single app to run continuously like this. If you have any other apps running, this will make you run over, and charges will likely result. But perhaps most importantly, all your other apps will immediately stop working. Paying $7/month for a hobby dyno will allow for a "web" dyno that never sleeps, and so this work-around won't be required.