-
Notifications
You must be signed in to change notification settings - Fork 0
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
get honey badger environment from system env var #47
Conversation
4f13162
to
c9d023b
Compare
@@ -11,5 +11,7 @@ notifications: | |||
email: false | |||
|
|||
env: | |||
secure: "lq31uKdO5F3IfUsfcmPIvmXkp2BOz56pjOAQ4S1RqHF4LoVH6LKMMd3Ocn0C9GyQfomM5NlKTRogFdJvB2iS6piXHej5iSo2/r5tmPxgX3BVMZwV6u9hEuE58U2sA+/NNwWZtivs+1U6XSRNwA2vi2qB8B5lePifCZjxsqL8l1doD4pwH+uDxXoYktberIAKizAzZFi03RvIaXHgPQYBADwrSYY4kbmrl1fL/jfdZx/ouSD055veIVJqQUGwsrdiq5lgtLSR8UfDzWZLQwDTiMLau7fJdE40lwPBAwpwDHPLdf1IGQfMih8y3YC4bQBNMi1w7J/T1nOpABvD8EZhHypYOHO/aYgWMmJM/EEzcytS52r1fieNoV3+GxxdSbOd6DN2D+hrGnZ34c3sQ8UZWXv6/PZtBBIcOsw132cQ35dOSXx78khg129IauW+RiQ5bRglZMr0Su6Pz3AL7az1CG0IDzzlJC+vmcobPLDTHJWpXIO2dyv/NyzfD0d5tYc9I1Y2/KeLUBxEm6x2GZw/dSQRih9YsZc7FXTyReNE5TQ8qGrDhpKGswr4c8MxW/3Dyktb0VwO2TlCfXwB0QKyTdd5QFSNYZ6OJyn1uPY/jHpTEzYxGAIVVFbWBwyv6NkjsIuFzhyLaOtmp6klHTdqcdFSExtIpL+8QoRmvWM06dc=" | |||
global: | |||
- WOWZA_HONEYBADGER_ENV=travis_honeybadger_env |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe we can do this one in travis itself, if not both of them. https://travis-ci.org/sul-dlss/dlss-wowza/settings
I use ENV variable for travis builds when I set up code coverage with CodeClimate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sure, happy to do it in settings instead, i was just staying consistent with what was there.
should i move both and get rid of that section entirely?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
now setting these env vars in project settings on travis-ci.org, removed them from .travis.yml
c9d023b
to
9aa27f4
Compare
@@ -34,8 +34,8 @@ | |||
{ | |||
static String stacksTokenVerificationBaseUrl; | |||
static String stacksUrlErrorMsg = "rejecting due to invalid stacksURL property (" + stacksTokenVerificationBaseUrl + ")"; | |||
static final String HONEYBADGER_KEY = "WOWZA_HONEYBADGER_API_KEY"; | |||
static final String HONEYBADGER_ENVIRONMENT = "WOWZA_ENVIRONMENT"; | |||
static final String HONEYBADGER_KEY_ENV_VAR = "WOWZA_HONEYBADGER_API_KEY"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would rename these. The names are too similar for me, and ENV_ENV makes me uncomfy.
Maybe: HB_API_KEY_NAME and HB_VM_ENV_NAME ??? with a comment saying they are environment variables???
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ha, i'm always worried i'm being too verbose in my naming, but agreed, will change.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok, the names are less similar, though i went with your earlier suggestion for the API key, and something slightly different than the above suggestion for the env name (so HONEYBADGER_API_KEY_ENV_VAR
, and HONEYBADGER_ENV_NAME_ENV_VAR
, respectively).
i do like the HONEYBADGER_*_ENV_VAR
naming convention in general, since they're honeybadger related system environment variables, but hopefully this addresses the ENV_ENV
concern (which made sense), and hopefully the immediate differences after HONEYBADGER_
make the names easier to differentiate at a glance.
as mentioned f2f, I suggest some info should go in the README about what you have to do while developing. |
pushed up the README change already |
- `WOWZA_HONEYBADGER_API_KEY`: You can get the API key from our [Honeybadger](https://www.honeybadger.io/) project (`DLSS-Wowza`). Note that you may need to get added to the `DLSS-Wowza` project as a user in order to obtain the key (someone from Devops should be able to add you). | ||
- `WOWZA_HONEYBADGER_ENV`: Anything other than the names of the deployed environments should be fine. E.g., something like `dlss_wowza_laptop_$USER`. | ||
|
||
If the environment variables are not set, your tests will fail. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
…r name (HONEYBADGER_KEY -> HONEYBADGER_API_KEY_ENV_VAR). update tests.
93a1ed0
to
04e7429
Compare
…. remove from .travis.yml.
…hard coding * rename HONEYBADGER_ENVIRONMENT to HONEYBADGER_ENV_NAME_ENV_VAR (since we get the environment string from the env var now) * test new behavior (analogous to honeybadger API key test) * update README
04e7429
to
3733abd
Compare
ok, took a shot at addressing the concerns raised above |
@@ -156,17 +156,23 @@ public void initHoneybadger() | |||
if(environment == null) | |||
environment = new SulEnvironment(); | |||
|
|||
String apiKey = environment.getEnvironmentVariable(HONEYBADGER_KEY); | |||
String apiKey = environment.getEnvironmentVariable(HONEYBADGER_API_KEY_ENV_VAR); | |||
String honeybadgerEnv = environment.getEnvironmentVariable(HONEYBADGER_ENV_NAME_ENV_VAR); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
technically, these could be considered static constants. But I don't really mind them as is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well... normally i'd be in favor of making stuff constant where possible... but in this case, i think we can't do that at class declaration time, because the values come from environment
, which doesn't get initialized until object instantiation.
One last minor line comment. It's okay if you disagree. |
instead of hard coding it. also, in a separate commit, a minor variable renaming for accuracy/consistency (happy to pull that if people think it's a bad idea).
connects to #46