search

phptek / silverstripe-sentry

Flexible Sentry compatible bug aggregation client for Silverstripe applications.
BSD 3-Clause "New" or "Revised" License
12 stars 22 forks source link

DSN config confusion #48

Open dcentrica opened 4 years ago

dcentrica commented 4 years ago

At the moment devs can configure Sentry's DSN either by using YML config or .env using SENTRY_DSN. If devs need fine-grained control on how reporting works on an environment by environment basis (ala dev, test and live) this can only be done in YML. Unfortunately, if you also have, (or want or need) SENTRY_DSN in .env then this config trumps the YML leaving you unable to do this.

Solution: Given that .env will always trump the YML config system, simply add a new module-specific directive SENTRY_ENV which does the same thing. A quick solution would permit one of "live", "dev" or "test" as its value:

SENTRY_DSN=http://deacda9dfbdb24cccce11b90517b39dca:feacdf9dfedb36ccdceab90017b39dca@sentry.mydomain.nz/44
SENTRY_ENV=live
Firesphere commented 3 years ago

Your solution sounds quite convoluted. The module can already detect the status of the site (live/test/dev). A more logical solution would be to have the following in .env SENTRY_DSN_LIVE=https://valid-dsn@sentry.mydomain SENTRY_DSN_DEV=https://valid-dsn@sentry.mydomain

et cetera.

And if there's no key defined for the given environment, it doesn't load.

That being said, I personally feel this is quite far fetched. As the .env or _ss_environment files in production are not supposed to be the same anyway, and having dev and live and test environments report to the same Sentry endpoint is far from ideal....

dcentrica commented 3 years ago

@Firesphere you're right. I'm tempted to revert to using YML config in my own projects TBH.

Firesphere commented 3 years ago

@dcentrica I personally feel using .env is better, because less chances of errors, but whichever works best for you, works. It's not like my preference is the law or anything :laughing: