Thoughts on adding database.yml to .gitignore

Because most, if not all, people that use foreman in production are
likely to switch to something other than sqlite for their database,
and will have a custom database.yml, I'm thinking it should be in
.gitignore.

The question, is should we also stop shipping a database.yml and
replace it with database.yml.example, or should we just add
database.yml to gitignore?

The implications of switching to an example file, is that there will
be an additional step in setting up foreman in a test environment.
This will require updating the install instructions, and will likely
impact those folks doing packaging.

Thoughts? (Also is the best place to have this conversation in redmine or here?)

I added a ticket here: Refactor #1624: Add database.yml to .gitignore - Foreman

Thanks,
Brian

I went ahead and issued a pull request based on a ticket comment.
https://github.com/theforeman/foreman/pull/52

··· On Sat, May 19, 2012 at 12:54 PM, Brian Gupta wrote: > Because most, if not all, people that use foreman in production are > likely to switch to something other than sqlite for their database, > and will have a custom database.yml, I'm thinking it should be in > .gitignore. > > The question, is should we also stop shipping a database.yml and > replace it with database.yml.example, or should we just add > database.yml to gitignore? > > The implications of switching to an example file, is that there will > be an additional step in setting up foreman in a test environment. > This will require updating the install instructions, and will likely > impact those folks doing packaging. > > Thoughts? (Also is the best place to have this conversation in redmine or here?) > > I added a ticket here: http://theforeman.org/issues/1624 > > Thanks, > Brian

I don't see a problem here. The packages should be easy to update to
match when the pull request gets merged, and the foreman-installer
module sets up it's own database.yml file anyway.

So, I am hugely in favour of this change.


Greg Sutcliffe
OpenPGP -> KeyID: CA0AEB93

··· On Sat 19 May 2012 18:37:26 BST, Brian Gupta wrote: > The implications of switching to an example file, is that there will > be an additional step in setting up foreman in a test environment. > This will require updating the install instructions, and will likely > impact those folks doing packaging.

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > The implications of switching to an example file, is that there will
> > be an additional step in setting up foreman in a test environment.
> > This will require updating the install instructions, and will likely
> > impact those folks doing packaging.
>
> I don't see a problem here. The packages should be easy to update to
> match when the pull request gets merged, and the foreman-installer
> module sets up it's own database.yml file anyway.
>
> So, I am hugely in favour of this change.
>

was already merged :wink:

··· On Mon, May 21, 2012 at 12:43 PM, Greg Sutcliffe wrote: > On Sat 19 May 2012 18:37:26 BST, Brian Gupta wrote:

Greg Sutcliffe
OpenPGP -> KeyID: CA0AEB93
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+6DlkACgkQ8O7RN8oK65MBrwCggfwkPA99nqtkv7J4h22wlHaU
5rYAnj02ef0AI4yBtZFKnA1R0DZrhtE+
=WZm/
-----END PGP SIGNATURE-----

Eeek!

quickly updates nightly package

:slight_smile: