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

Idea: Add per-environment global variables #18

Closed
kydorn opened this Issue May 4, 2016 · 8 comments

Comments

Projects
None yet
2 participants
@kydorn
Contributor

kydorn commented May 4, 2016

It would add a lot of flexibility being able to specify global environment variables, that apply only to a specific environment, but to all templates.

Like any other global variable, it could be overriden by template-specific variables.

@markround

This comment has been minimized.

Show comment
Hide comment
@markround

markround May 4, 2016

Owner

Hi, Thanks for the suggestion. Do you have an example for how you'd like to see it working ?

Owner

markround commented May 4, 2016

Hi, Thanks for the suggestion. Do you have an example for how you'd like to see it working ?

@kydorn

This comment has been minimized.

Show comment
Hide comment
@kydorn

kydorn May 4, 2016

Contributor

Sure, for example:

data_sources: [ 'defaults', 'file' ]
template_sources: [ 'file' ]
defaults:
    global:
      variable: 'default value'
    template.erb:
       ...
    template2.erb:
       ...
environments:
    development:
      global: 
        variable: 'default value for development environment'
      template.erb
         variable: 'local value for template.erb'
    staging:
      global: 
        variable: 'default value for staging environment'
    production:
     ...

This is specially useful when we are sharing the same variable between multiple templates and different environments. If we need the same variable to be consistent in an environment, we currently have to define it for each template that uses it (and for each environment)

Contributor

kydorn commented May 4, 2016

Sure, for example:

data_sources: [ 'defaults', 'file' ]
template_sources: [ 'file' ]
defaults:
    global:
      variable: 'default value'
    template.erb:
       ...
    template2.erb:
       ...
environments:
    development:
      global: 
        variable: 'default value for development environment'
      template.erb
         variable: 'local value for template.erb'
    staging:
      global: 
        variable: 'default value for staging environment'
    production:
     ...

This is specially useful when we are sharing the same variable between multiple templates and different environments. If we need the same variable to be consistent in an environment, we currently have to define it for each template that uses it (and for each environment)

@markround

This comment has been minimized.

Show comment
Hide comment
@markround

markround May 5, 2016

Owner

Right, I see. Let me have a think about this, and I'll see if I can add something like that for you.

Owner

markround commented May 5, 2016

Right, I see. Let me have a think about this, and I'll see if I can add something like that for you.

@markround

This comment has been minimized.

Show comment
Hide comment
@markround

markround May 5, 2016

Owner

Just committed b24073d , which I think will do what you're after. Take a look at the test fixtures:

And the tests themselves, which show the expected output : https://github.com/markround/tiller/blob/feature/per_env_global/features/file_globals.feature

It looks pretty much like what you were after. It was a very simple change, I just made the file datasource pick up a new global_values: block, and you can also use the defaults datasource to specify a default.

Is this OK for you ?

Owner

markround commented May 5, 2016

Just committed b24073d , which I think will do what you're after. Take a look at the test fixtures:

And the tests themselves, which show the expected output : https://github.com/markround/tiller/blob/feature/per_env_global/features/file_globals.feature

It looks pretty much like what you were after. It was a very simple change, I just made the file datasource pick up a new global_values: block, and you can also use the defaults datasource to specify a default.

Is this OK for you ?

@kydorn

This comment has been minimized.

Show comment
Hide comment
@kydorn

kydorn May 5, 2016

Contributor

Yup, that would do the trick! Thank you so much for this fast response :)

Contributor

kydorn commented May 5, 2016

Yup, that would do the trick! Thank you so much for this fast response :)

@markround

This comment has been minimized.

Show comment
Hide comment
@markround

markround May 5, 2016

Owner

Great :) OK, I'll add some notes to the documentation, tidy it up a bit and get a release out ASAP (probably tomorrow). I'll give due credit for the suggestion in the Changelog, would you like me to reference your GitHub ID/website/blog/whatever ?

Owner

markround commented May 5, 2016

Great :) OK, I'll add some notes to the documentation, tidy it up a bit and get a release out ASAP (probably tomorrow). I'll give due credit for the suggestion in the Changelog, would you like me to reference your GitHub ID/website/blog/whatever ?

@kydorn

This comment has been minimized.

Show comment
Hide comment
@kydorn

kydorn May 5, 2016

Contributor

You could use the handler if you want, but there is no need. I'm actually using Tiller at work for creating a hierarchical configuration for docker containers and I just was too lazy to learn ruby and change it myself. Thank you so much for your work!

Contributor

kydorn commented May 5, 2016

You could use the handler if you want, but there is no need. I'm actually using Tiller at work for creating a hierarchical configuration for docker containers and I just was too lazy to learn ruby and change it myself. Thank you so much for your work!

@markround

This comment has been minimized.

Show comment
Hide comment
@markround

markround May 5, 2016

Owner

Resolved by v0.7.7. An updated gem will be built and released shortly. Thanks again for the suggestion!

Owner

markround commented May 5, 2016

Resolved by v0.7.7. An updated gem will be built and released shortly. Thanks again for the suggestion!

@markround markround closed this May 5, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment