What's the best way to allow people to fork and configure a Rails app while keeping pull requests simple? #6

cantino opened this Issue Mar 17, 2013 · 4 comments


None yet
2 participants

cantino commented Mar 17, 2013

Right now contributing to Huginn while keeping your personal changes private is somewhat difficult.

You can fork Huginn and then make a private remote of the fork, but pushing changes from the private duplicate is difficult without leaking your personal configuration, unless you're very careful about how you structure your branches.

Should we move all configuration into a single .gitignored YAML file? Or would it be better if this was a Rails engine?

Hey, here's my (two-part) suggestion:

  1. Move all environment variables into a YAML or Ruby file in the config folder. Add the actual file to .gitignore but include a copy of it in git, called huginn.yml.example, so that people can make their own.
  2. Change the example YAML file to an ERB template for the file, and use a Thor script to populate this template. Thor's got some great actions (like ask) that make it super easy to generate command prompts (imagine sound card configuration circa 1992 video games).

Other stuff:

  • Add a Thor task to make it easy to add/delete invitation codes
  • After editing something that requires a restart of the Rails server... restart the Rails server.
  • In fact, maybe Thor can handle booting all services in the required order. 😄

One more thing: if you really want to get MVC with it, make a HuginnConfigurator class that can both write out to a configuration file AND read from an existing configuration file, so that if you run the setup task again the default values are pulled from your current config.


cantino commented Mar 17, 2013

I think this is the right direction. Do you know of any examples of Rails apps that are configured in this way?

We used to do something like this at my FT job for our developer tools (now all of are environments are provisioned using Vagrant and Chef). I think .gitignoring your environment specific yml files (even database.yml) is a pretty standard thing to do.

@cantino cantino closed this Apr 1, 2013

drcapulet pushed a commit to drcapulet/huginn that referenced this issue Jul 31, 2014

Merge pull request #6 in SQ/huginn from samsa to master
* commit '45d95128b487d11ba514ac2aa5abe0345f9a5f39':
  Curl instructions for spamming errors.
  Add every_1s to our list of changes.
  Speed up delayed worker to match every_1s schedule.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment