Open pdxdiver opened 7 years ago
Thanks for the guard rails to avoid the avoidable firedrill we just went through today.
Recommendation:
I would like to see us using environment variables named more precisely for what they represent, so that we avoid any perceived ambiguity across teams or engineers who may not be watching closely.
e.g. I'd recommend calling it "AWS_ACCESS_KEY_ID" (since the "ID" shows up in the name in AWS console) rather than "AWS_ACCESS_KEY" (which is marginally shorter but could be mistaken for SECRET_ACCESS_KEY if someone's not careful).
Is there a reason we should avoid AWS_ACCESS_KEY_ID?
"AWS_ACCESS_KEY_ID" (since the "ID" shows up in the name in AWS console)
I suggest an even more detailed name, such as:
This is especially useful for people who are working on more than one project that uses AWS.
If Hack Oregon uses different deployment environments for stages of release, you might want to put an environment level in that name too: HACK_OREGON_BUDGET_env_AWS_ACCESS_KEY_ID, such as:
take a look at new .travis.yml file. externalized AWS secrets. Please add:
to your travis-ci.org web config with new keys that will be provided