Added an example to show how common secrets can be shared across multiple environments in secrets.yml

[prathamesh-sonpatki]

• Earlier, if there were common configurations under all environments then
  they had to be duplicated under each environment in
  config/secrets.yml.
• This commit adds a way to specify them under common key such that
  they will be loaded in all environments.
• Environment specific configurations will override the common configurations if they
  are present under both sections.

Edit

Common secrets is a bit confusing here. I meant to say common configuration options or settings like lets say default_from_email_address. It can be support@example.com in development, test and in production can be something else.

[vipulnsward]

👍
We use this all the time to share common configurations.

[simi]

What about to add this to all YAML configurations? For example to ActiveRecord's database.yml.

[mechanicles]

👍

[prathamesh-sonpatki]

@simi Good point. I think if we agree to add it for secrets.yml then we can also add it for other files.

[matthewd]

What does this offer over using YAML's built-in anchor/reference syntax?

[prathamesh-sonpatki]

@matthewd You are right. Same functionality can be achieved using YAML's anchor/reference syntax. This is just another way to do it.

[egilburg]

I'm concerned that providing documented application API to do so would encourage this practice which IMO is an anti-pattern (at least as far as presenting it to new users go), as secrets by their nature are best not to reuse across environments, especially in the most common case of production vs non-production.

For someone who went beyond the basics and has a bona fide use case for this (for example, multiple production envs who need to share secret for communicating with each other), as mentioned in comments, this could be done manually using .yaml reference syntax.

[senny]

We use the YAML reference syntax already in our database.yml templates. We should keep using that instead of introducing a new concept. To make it easier to use that pattern, we could prepare the template accordingly.

[prathamesh-sonpatki]

@senny I agree. What do you mean by To make it easier to use that pattern, we could prepare the template accordingly.

[vipulnsward]

Add an example for YAML linking in default file generated.

On Sunday, April 26, 2015, प्रथमेश notifications@github.com wrote:

@senny https://github.com/senny I agree. What do you mean by To make it
easier to use that pattern, we could prepare the template accordingly.

—
Reply to this email directly or view it on GitHub
#19898 (comment).

Vipul A.M.
+91-8149-204995

[prathamesh-sonpatki]

@senny Updated the PR. The only issue I think is development and test environments will have same secret_key_base. Or should we add a commented example for showing how secrets can be shared?

[senny]

@prathamesh-sonpatki better add a commented example. I don't think development and test should share their secret.

[prathamesh-sonpatki]

@senny Updated. Please check.

[prathamesh-sonpatki]

@senny What do you think about this?

[senny]

@prathamesh-sonpatki it's on my list. Please don't make ping comments continuously. We get enough emails as is.

[senny]

Looking at the example I don't think we should promote that in the file itself. What about only including the sentence:

# You can also share common secrets in multiple environments
# using YAML anchor/reference syntax.

Followed by a link to find more details.

[prathamesh-sonpatki]

Can we update the example to use api_url instead of api_secret? I like the idea of adding a link to actual docs also but would be good to have a example like we have in database.yml.

[senny]

In my projects I rarely find myself in the situation of sharing secrets with development and test environment.

Let's wait for more feedback before we decide.

/cc @sgrif @carlosantoniodasilva @rafaelfranca @chancancode

[prathamesh-sonpatki]

Ok. Here is an example of secrets.yml sharing settings - https://github.com/bigbinary/wheel/blob/master/config/secrets.yml.

Then all the initializers access these values throguh Rails.application.secrets.

[senny]

Yes, putting the ENV[] in the shared group certainly makes more sense.

[prathamesh-sonpatki]

I have updated the example to use ENV variables.

[sgrif]

This broke the build as the ERB is still interpolated, even though it's inside of a comment. Please re-open once you fix