feat(sentry): add starlite sentry integration

[gazorby]

Closes #52

[peterschutt]

So the way the sentry integration globally patches starlite means that if you run that failing test on its own, it passes as sentry.configure() has never been called. Once it is called at all, that test will fail as there is an exc. handler added in the init wrapper (as you know!).

So I think we just disable sentry for the tests, thoughts @gazorby?

[gazorby]

Yes it's better to disable it for unit tests, but maybe we can do something in the integration environement? I just saw that LifespanManager trigger lifecycle hooks, so we could try something like that:

from starlite import Starlite
from sentry_sdk.integrations.starlite import SentryStarliteASGIMiddleware

def test_sentry(app):
    old_init = Starlite.__init__
    async with LifespanManager(app):
        assert isinstance(app.middleware[0], SentryStarliteASGIMiddleware)
    Starlite.__init__ = old_init

[gazorby]

Also, what do you think about disabling sentry when ENVIRONMENT == "local"?

[peterschutt]

but maybe we can do something in the integration environement?

It would be nice to have the sentry integration enabled somewhere within the tests to pick up any side-effects of having it activated before deploying. I'd even be happy to run the whole integration test suite with it activated - perhaps we can use the app fixture in tests/integration/conftest.py, make it a yield fixture, and have the logic to "un-patch" starlite after the yield.

I've still got to fix that integration test that has been x-failed.

If you want to do it in this PR or another, I'm easy.

Also, what do you think about disabling sentry when ENVIRONMENT == "local"?

Yes, makes sense, and have the implicit setting able to be overridden by environment like we did for reloading.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

100.0% Coverage
0.0% Duplication