-
Notifications
You must be signed in to change notification settings - Fork 3
feat: create barebones sentry webhook endpoint #59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is ✅ All tests successful. No failed tests found.
❌ Your patch check has failed because the patch coverage (34.09%) is below the target coverage (90.00%). You can increase the patch coverage or adjust the target coverage. 📢 Thoughts on this report? Let us know! |
Codecov ReportAttention: Patch coverage is
✅ All tests successful. No failed tests found.
Additional details and impacted files@@ Coverage Diff @@
## main #59 +/- ##
==========================================
- Coverage 94.20% 94.14% -0.06%
==========================================
Files 1199 1200 +1
Lines 44890 44934 +44
Branches 1431 1431
==========================================
+ Hits 42288 42303 +15
- Misses 2300 2329 +29
Partials 302 302
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
d7bd990
to
c8fbbf9
Compare
This endpoint will be called by the webhook forwarding code in Sentry. We're using the existing Sentry -> Codecov communication method where we validate that the request is indeed coming from Sentry to authenticate. So the Sentry is using the CodecovApiClient to make the request and we're using the JWTAuthenticationPermission here. We could have implemented this as part of the existing Github webhook endpoint but that would've made its implementation more complicated so I made the choice to have another endpoint that handles post requests separately but still uses the Github endpoint's functionality for processing webhooks. For now, I want to "dry run" processing the webhooks here, which is why I wrap the handling of webhooks around a transaction. This might be a bad idea if we're going to have conflicting writes to similar rows, which is a possibility with handling webhooks. I've checked that the push and pull_request webhooks make their writes to the db at the end of the handling. I think it should be unlikely we often get conflicting writes for the installation webhooks. In that case it might be worth it to rewrite the webhook handlers to allow "dry_run" variants where no writes are actually made. We must also consider cases where a User has installed both the Sentry app and the Codecov app, which could be a common case, we should only handle webhooks that we receive from Sentry in that case, so we'll have to add some bookkeeping for that, but that's for the future, when the Sentry webhook handler will be responsible for writing.
c8fbbf9
to
f8ca204
Compare
with transaction.atomic(): | ||
# this looks weird but we're basically doing "dry runs" | ||
# of the webhook handling | ||
|
||
# this will eventually be removed once we validate it's working | ||
# correctly in prod | ||
transaction.set_rollback(True) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lets hope the assumption that we can use transaction rollback for this actually works out, lol
No description provided.