-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cater to --settings #4
Comments
Hi Tim, What would be a better way to do this do you think? You could have something like |
Some people like to keep things like production passwords away from their main repos right, which is why you're hesitant? I'm not entirely clear on what the various options are, but the scenario I had yesterday wasn't dealing with sensitive information - I just wanted a way to provide various settings that should be in the production environment only. One alternative is to have our (under construction) deploy process setup METEOR_SETTINGS pulling together information from wherever it needs. How are you dealing with this yourself? It seems like it would be useful to cater to --settings in some way though to support what's provided by meteor. |
Previously I've just used a whole bunch of I'm not really sure how |
Any thoughts on this? |
Just migrating to heroku/meteorite and I have the same problem. I do have production settings in a non-commited file. This works well and I am happy with this solution:
|
Nice tip, thanks :) |
@sarfata this is a very nice trick! Thanks! 👍 |
Meteor has a --settings option now, that is used to specify a path to a json file to load into Meteor.settings. It would be nice if the buildpack catered to --settings.
I took a look at it this morning, but couldn't figure it out. Setting Heroku env var METEOR_SETTINGS is an ugly work around..
The text was updated successfully, but these errors were encountered: