For a long time I was storing hubot's env vars in my local repo and managing them by simply sourcing the files like so:
$ source ./shell-config # file eg. export HUTOT_ENV_VAR="..."
$ source ./heroku-config # file eg. heroku config:add HUBOT_ENV_VAR="..."
When reusing the same configuration variables in development and production environments I've found it easier just to specify hubot's env vars in a single json file that gets called at runtime.
Maybe others will find it useful as well...
Adds -i, --config PATH option to bin/hubot.
-i, --config PATH
$ bin/hubot --config config.json
$ bin/hubot -i config.json
Which in turn adds the configuration vars to process.env to be used by hubot scripts.
hubot is vip on all my teams, major thx github
allow loading of env vars via configuration json file
Yo I love the idea but some of the code freaks me out. Ping me back in a few days and I'll take a stab at replicating the functionality in a way that feels more like the rest of the codebase.
Totally understandable, definitely agree wrapping the core code here in a next() callback is less than appealing. The multiple do next calls aren't much better. I haven't spent a ton of time in hubot's internals so there's probably a better way to address this all together.
Something like this possibly...
loadConfig = ->
configPath = Path.resolve Options.config
Path.exists configPath, (exists) =>
config = require configPath
for own attr, value of config
process.env[attr] = value
loadScripts = ->
loadConfig() if Options.config
robot.adapter.on 'connected', loadScripts
Still doesn't account for making sure the config vars are loaded before rubot.run() is called but generally involves less 💩
Note: The idea behind using require instead of Fs.readFile was to provide the option to pass --config config.coffee or --config config.js in the case a dynamic config is needed. I've yet to use it myself so maybe that's premature / overkill.
Either way, thanks much for checking it out @atmos definitely appreciate it 🍻
If you are running on Heroku, you can keep your environment variables in a .env https://devcenter.heroku.com/articles/config-vars#local-setup maybe have a solution similar to https://github.com/bkeepers/dotenv
Yeah, I would use something like bkeepers/dotenv and ddollar/foreman for this.
Closing as you can use .env if you're using foreman which is what Heroku uses.