The above Git command was necessitated after utilizing the Figaro gem to create environment variables for secure authentication. For additional questions or concerns, consult the Git Prune documentation. DISCLAIMER: Pragmatically, and for the love of Git, avoid the agony below by including secrets.yml in .gitignore FIRST, then git add ., git commit -m, then create the secrets.yml file, otherwise,
if using Rails 4.1 or newer, secret keys should be created in config/secrets.yml, and set differently based on the environment. In this case, generate a random token and set it as ENV['SECRET_KEY_BASE’] to use at a staging-area, like Heroku. Run rake secret from the command line to generate a token, and heroku config:set SECRET_KEY_BASE=thegeneratedtoken to set that token to that ENV variable on production.
Add SECRET_KEY_BASE to your application.yml, then use Figaro to sync the tokens on Production and Development. Next, set the Development key to equal the same ENV-stored token as the Production key in secrets.yml. This creates individual, unique tokens for development and production environment variables.
Presumably, the aforementioned effected, so now would be a good time to verify if application.yml and secrets.yml files are contained within the .gitignore file; even if these files are already included within .gitignore, in my experience, an immediate commit, merge to master and push to origin could expose these files, especially if secrets.yml wasn’t initially input into the .gitignore file, then added and finally committed before creating the actual secrets.yml file (implored by the disclaimer introducing this blog post), which obviously defeats the purpose of authentication-so, to ensure security, add, commit, merge to master, but before pushing to origin, consider the following answer in response to this post from StackOverflow: Ignore files that have already been committed to a Git repository:
To untrack a single file that has already been added/initialized to your repository, i.e., stop tracking the file but not delete it from your system use:
git rm --cached filenameTo untrack every file that is now in your .gitignore:
First commit any outstanding code changes, and then, run this command:
git rm -r --cached .This removes any changed files from the index(staging area), then just run:
git add .Commit it:
git commit -m ".gitignore is now working"To undo:
git rm --cached filename, usegit add filename.
The above process should correctly account .gitignore specifications for secure authentication, regardless of sequence.
Alternatively, for Heroku deployment, you may consider the following remediation via the HerokuSecrets gem developed by Alex Peattie sourced in my answer to the following post at StackOverflow: Rails app fails to compile on Heroku because of Devise secret_key, provided thusly:
My application was reporting the same error, however, the issue results from a combination of using the Figaro gem and rigid systemAdmin. Upon implementing the Figaro gem, creating a secrets.yml file for assigning authentication tokens, then appropriately storing it within .gitignore, a conflict can occur when attempting to deploy to heroku because the .gitignore prevents pushing the secrets.yml file credentials necessary for deployment.
Specifically, I used the following gem and procedure to resolve the conflict:
gem 'heroku_secrets', github: 'alexpeattie/heroku_secrets'bundle installgit push heroku master --forceThe abovementioned solution is explained further in a related StackOverflow post: StackOverflow: How do you manage secret keys and heroku with Ruby on Rails 4.1.0beta1?
Please feel free to comment on my Gist at Github or use the below forms. I’d really appreciate any recommendations or suggestions if need be. Thank you!