Project specific environment variable

[praveenram]

Added a feature to set some environment variables during creation of project, specific to the project.

Use case:

Without branching out, to test out features in the project which are toggled by use of environment variables.

In this case we cannot use the goldberg_config.rb to change the command that is executed, for instance let it be:

rake spec

Instead we can set the environment variable while creating the project:

bin/goldberg add https://github.com/user/repo repo_ci --branch master --scm git --env foo=bar foobar=zoo 

So then while running the build, the command which will be called is:

foo=bar foobar=zoo rake spec

If the config.environment_string is also set to say "bar=foo" then it will be called as:

foo=bar foobar=zoo bar=foo rake spec

[srushti]

Thanks for the PR. Ideally, I wouldn't want the environment variables in the DB. There's already two places they can be in. The checked-in goldberg_config.rb & the non-checked-in goldberg_config.rb in the .goldberg/projects folder. Considering that, could you change it to generate the non-checked-in goldberg_config.rb file with the environment variables in the appropriate place?

[praveenram]

Thats a good idea. I hadnt noticed that block of code where you read from the project repository or the home folder for project. Will make the change and create a new request.

As a user how valuable do you think is this feature? Would you have any use case for it?

On Mon, Sep 23, 2013 at 9:15 PM, Srushti Ambekallu <notifications@github.com

wrote:

Thanks for the PR. Ideally, I wouldn't want the environment variables in the DB. There's already two places they can be in. The checked-in goldberg_config.rb & the non-checked-in goldberg_config.rb in the .goldberg/projects folder. Considering that, could you change it to generate the non-checked-in goldberg_config.rb file with the environment variables in the appropriate place?

— Reply to this email directly or view it on GitHubhttps://github.com/srushti/goldberg/pull/157#issuecomment-24929886 .

[srushti]

About the use case, I don't know. There's already convenient way to set the environment variables in the config file that you check in. And that'll be maintained even if you happen to set up a new server.

Let me turn around the question to you: what made you build the feature? Presumably, you ran into a situation where you thought this would be handy.

[praveenram]

So here is why I wanted it. I have one branch of code a rails app, and I deploy that site as two completely different sites based on an environment variable. The basic workflow is the same, just the look and feel of the site is slightly different.

So I need to be able to test it as well for both sites. Given that its the same branch, I cant change the checked-in golderg_config.rb. So I need an external control which is not part of the repository, but more like a runtime or setup time configuration.

I felt the db was ideal because in the future, if we needed to set a different value to one of the variables, it might be simpler to modify while still keeping all the build history. Though the solution above is string based, it can be altered to be made a key value store as well in the db.

[srushti]

I wonder, if we could let users edit the non-checked-in file through the web app. It could just dump the entire file in a text area, and let the users change it however they want. This probably means we want to always generate a stub version of the file when a project is added with no settings. That way they can they edit the project-specific (and by project, I mean it in the Goldberg sense) config without having to ssh in.

What do you think?

[praveenram]

Ya if we could change the web interface to be able to edit this, either as a text dump or as a form with all possible configuration values, it would be good as well.

It would also mean that we have to take the effective config as a union of the local (non-checked in config) and the checked-in project config at all times. Is that already designed that way.

On a totally unrelated note, I feel that there should be only one config file, as a general guideline. If we could bring enough control of the configuration onto the web app, users can make all their project specific configuration on the web app itself. Without even having to check in the goldberg_config.rb to their repositories.

[srushti]

This is still for programmers. So, I would want to continue to use the code version of it. We'd probably want to add a sample file on the side (like the one in the README) on the side to suggest what they could edit.

On the case of the single config file, the reason we have two is because I'm a fan of checking in configurations. But at the same time, I like to be able to have different configurations if I add the same repo multiple times (like I have at goldberg.ambekallu.com where goldberg has been added with multiple ruby versions). Goldberg merges both configurations, and the not-checked-in one has priority over the checked-in one when the same setting is in both.

[praveenram]

Great that makes sense. I'll modify it to write the environment variable that is added during project creation to the local non-checked-in file and maybe we could add some of the information from this thread as part of the README.

[praveenram]

As an initial step I've just made the environment variables to write to the local (non-checked in) goldberg_config.rb file. Let me know how that looks.

[srushti]

Looks good. I'll merge this in later this evening. Thanks for this.

[praveenram]

I just noticed there is a bug with this, it takes only the first parameter specified after --env. I'll fix this and send a new pull request for that fix. Thanks.

[srushti]

Closing this, since we'll be bringing in any changes only in a new PR.