Set the global bundle config property as an application specific property. Push the changes to the public repository. Update the SECRET_TOKEN
value in the bundle-config file ($APP_DIR/.bundle/config
) and run the $ git update-index --assume-unchanged <file>
command to remove the file from git tracking and prevent updating the actual SECRET_TOKEN value in the public repository.
$ bundle config --local gem.fury.io SECRET_TOKEN
$ git commit -a -m "adding application bundle config properties"
$ git push origin master
$ bundle config --local gem.fury.io d1320f07ac50d1033e8ef5fbd56adf360ec103b2
$ git update-index --assume-unchanged $APP_DIR/.bundle/config
This creates a template file on the public repository. Provide instructions to repository contributors to add the secret token and execute the same --assume-unchanged command.
Example Files
$APP_DIR/.bundle/config file on public github repo:
---
BUNDLE_GEM__FURY__IO: MY_SECRET_TOKEN
$APP_DIR/.bundle/config file a local machine
---
BUNDLE_GEM__FURY__IO: d1320f07ac50d1033e8ef5fbd56adf360ec103b2
See bundle-cofig documentation for clarification and more detail
NOTE: The disadvantage to this approach is two fold:
- Developers who clone the repository and need the
SECRET_TOKEN
value will have to obtain it by some external manual process (good security practices, but a pain to set up)
- If you need to add more bundle-config properties, you will have to run
git update-index --no-assume-unchanged <file>
to enable tracking, and revert all of the private values to their pseudo values. This template method, also risks that contributors forget to disable tracking on the file and push their private values to the public repo (but at least they won't be your secret values)
The advantage of this template approach is that you are giving the developers as much as possible to be able to start contributing to the repository.