Skip to content

allow loading of env vars via configuration json file #364

wants to merge 1 commit into from

4 participants

ecarter commented Nov 5, 2012

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.


$ bin/hubot --config config.json


$ bin/hubot -i config.json

Example 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 :octocat: :metal:

atmos commented Nov 5, 2012

/cc @rtomayko

atmos commented Nov 8, 2012

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.

ecarter commented Nov 8, 2012

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) =>
      if 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 is called but generally involves less 💩

Note: The idea behind using require instead of Fs.readFile was to provide the option to pass --config 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 🍻

tombell commented Nov 19, 2012

If you are running on Heroku, you can keep your environment variables in a .env maybe have a solution similar to

jroes commented Dec 7, 2012

Yeah, I would use something like bkeepers/dotenv and ddollar/foreman for this.

tombell commented Jan 10, 2013

Closing as you can use .env if you're using foreman which is what Heroku uses.

@tombell tombell closed this Jan 10, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.