feat: add new config `SENTRY_OPTIONS` for more flexible Sentry configuration
The Sentry SDK has several options, but right now we are limited by errbot as to which one can be configured.
This adds a new SENTRY_OPTIONS config, which enable users to specify any option supported by the SDK in the sentry_sdk.init() call.
Our use case is that we have 2 instances of a given bot running, one for testing changes to our plugins and one which we use (like staging & prod) and we use the environment option to tell which bot caused the error. I assume some people might find the release option useful too.
Is there a way to consolidate all the sentry options into this new option, basically removing SENTRY_TRANSPORT?
Sure, can do that. That would be a breaking change, is it something that we should deprecate first?
@browniebroke that's a fair concern. There is some planned work that may cause other breaks too.
Would you be ok with creating a separate PR with the separate breaking changes?
Yes sure :+1:
@browniebroke With the single SENTRY_OPTIONS option now, how could someone specify a different transport?
@browniebroke With the single
SENTRY_OPTIONSoption now, how could someone specify a different transport?
They would specify it as per the Sentry docs, but to be honest, that's not super clear over there. I looked into their tests and I found an example here:
https://github.com/getsentry/sentry-python/blob/6db44a95825245b1f7c9baa54957d044f7be18eb/tests/tracing/test_integration_tests.py#L245-L254
I think the transport has been simplified compared to the old Sentry client (Raven) which was providing multiple transport classes: https://docs.sentry.io/clients/python/transports/
The newer client sentry-sdk is lighter on the topic: https://docs.sentry.io/platforms/python/guides/airflow/configuration/options/#transport-options
Let me know if I missed anything. I'm not sure it's worth expanding more on this in the docs?
@browniebroke Does the PR https://github.com/errbotio/errbot/pull/1605 superseed this one or does this one need to be merged first before #1605?
It builds on top of it, so it's a bit of both.
If it was my project, I would probably merge this first and then merge the other, this way the 2 PR would appear as 2 distinct changes, but it's up to you. Depends how you like to separate things.