-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
feat: make system.secret-key
configurable from environment variables
#3783
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
Conversation
Closes #1226 Generate `SENTRY_SYSTEM_SECRET_KEY` with a secret value on `.env.custom`. This also introduces the usage of `.env.custom` across self-hosted deployment. Might break some people's automation though, but hopefully it won/t if they don't change their `sentry/sentry.conf.py` file.
Codecov ReportAll modified and coverable lines are covered by tests ✅
✅ All tests successful. No failed tests found. Additional details and impacted files@@ Coverage Diff @@
## master #3783 +/- ##
=======================================
Coverage 99.45% 99.45%
=======================================
Files 3 3
Lines 183 183
=======================================
Hits 182 182
Misses 1 1 ☔ View full report in Codecov by Sentry. |
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 don't think we should be creating an .env.custom
file automatically. It really complicates things.
Can we instead write the value into the config file (.py
one) if the env variable is not set? If it is set, we just use that one and replace the !!changeme!!
part with nothing forcing an execption to be thrown when the key is missing?
I made it much more simpler now. |
Co-authored-by: Amin Vakil <[email protected]>
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.
Love it!
# Sentry event retention days specifies how long events are retained in the database. | ||
# This should be set on your `.env` or `.env.custom` file, instead of modifying | ||
# the value here. | ||
# NOTE: The longer the days, the more disk space is required. |
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.
# NOTE: The longer the days, the more disk space is required. | |
# NOTE: The longer the days, the more disk space is required and 90 days is the maximum value you can use. |
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.
and 90 days is the maximum value you can use.
Actually, no. You can go for 365 days. See getsentry/sentry#94602
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, I was told many places in the system assume a maximum of 90 days that's why I suggested this. And the issue you linked kind of shows that? :D
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.
But still :D
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.
🤷🏻♂️
Co-authored-by: Burak Yigit Kaya <[email protected]>
Closes #1226
Generate
SENTRY_SYSTEM_SECRET_KEY
with a secret value on.env.custom
.This also introduces the usage of
.env.custom
across self-hosted deployment. Might break some people's automation though, but hopefully it won/t if they don't change theirsentry/sentry.conf.py
file.