DSN config confusion

[dcentrica]

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:[email protected]/44
SENTRY_ENV=live

[Firesphere]

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://[email protected]
SENTRY_DSN_DEV=https://[email protected]

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]

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

[Firesphere]

@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 😆