Initialised Sentry for Corpus

[imApoorva36]

Description

Initialised Sentry with required changes in settings.py as required.
The env variable for Sentry in the .env file can be given as :
SENTRY_DSN="<sentry_dsn_link_got_from_sentry>"

Fixes # 114

Dependencies

List any dependencies that are required for this change.

Type of Change

What types of changes does your code introduce?
Put an x in the boxes that apply

• [ x] New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• [x ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Please also list any relevant details for your test configuration. (for bug fix / breaking change)
Put an x in the boxes that apply

• Test A
• Test B

---

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[anirudhprabhakaran3]

Also, add the SENTRY_DSN variable to the example.env file with some random value.

[imApoorva36]

Also, add the SENTRY_DSN variable to the example.env file with some random value.

But for developers, each person's Sentry will not be the same right?
For example different developers will have unique sentry dsn right, so will giving it in env.example help?
Moreover, we aren't enabling sentry dsn for non-prod env right?

[anirudhprabhakaran3]

Yes, that's correct. However, the idea for the example.env is to just uniformly keep track of the .env file. In case (god hope it never does) the .env file goes wrong/gets deleted, we have an easy way to recreate everything.

[imApoorva36]

Yes, that's correct. However, the idea for the example.env is to just uniformly keep track of the .env file. In case (god hope it never does) the .env file goes wrong/gets deleted, we have an easy way to recreate everything.

Alright got your point, will do so, from what I understood, even thought it's in the env it'll never start for the dev since I've configured it to run only in the prod env...