Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

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

Closed
cantino opened this Issue · 4 comments

2 participants

@cantino
Owner

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?

@modality

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. :smile:
@modality

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
Owner

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

@modality

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.

@ghelleks ghelleks referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@cantino cantino closed this
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.