[DRAFT] feat: forward webhooks to codecov #92082
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
the
Scope: Backend
Forwarding webhooks for Sentry running in Monolith mode is considered out of scope for this change depends on: #91830 We want to forward webhooks Sentry receives to Codecov since Codecov depends on receiving webhooks from the code forges it supports. We're starting with only GitHub webhooks for now, but plan to support more in the future. We're using the existing WebhookPayload system to forward webhooks to Codecov by creating an additional WebhookPayload object in the GithubRequestParser. Codecov will do additional filtering on its end to filter out irrelevant webhooks so we don't have to do any filtering on Sentry's end, this is to avoid keeping track of what's relevant to Codecov in Sentry. I'm adding a destination_type column to the WebhookPayload so we can distinguish between payloads meant for Codecov and other Sentry regions because when we make the request in the drain_mailbox we want to run different logic, using the CodecovApiClient. I also made the choice to use a different mailbox_name so that the forwarding doesn't interfere with the webhooks being sent to the region silos. Finally, because we want to forward ALL webhooks to Codecov, that means we're forwarding installation events, a webhook that in Sentry gets processed in the control silo, so that gets its own mailbox identifier "installation".
joseph-sentry
force-pushed
the
joseph/webhooks
branch
from
7efb0f9 to
5ef0008
Compare
Codecov wants to receive the forwarded webhooks at a specific endpoint in a specific format, this is because we may want to have separate logic for processing webhooks forwarded from Sentry vs. directly received from github. The choice to include the event in the request body was just a preference since even though we're forwarding the webhook i want to discern that this is a request that Sentry is sending Codecov.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
TODO: make this work for monolith mode, i didn't consider monolith
mode when I made these changes. I think the path forward for that is
to define another middleware that takes care of that and only operates
in monolith mode.
depends on: #91830
We want to forward webhooks Sentry receives to Codecov since Codecov
depends on receiving webhooks from the code forges it supports. We're
starting with only GitHub webhooks for now, but plan to support more
in the future.
We're using the existing WebhookPayload system to forward webhooks to
Codecov by creating an additional WebhookPayload object in the
GithubRequestParser. Codecov will do additional filtering on its end
to filter out irrelevant webhooks so we don't have to do any filtering
on Sentry's end, this is to avoid keeping track of what's relevant to
Codecov in Sentry.
I'm adding a destination_type column to the WebhookPayload so we can
distinguish between payloads meant for Codecov and other Sentry
regions because when we make the request in the drain_mailbox we want
to run different logic, using the CodecovApiClient.
I also made the choice to use a different mailbox_name so that the
forwarding doesn't interfere with the webhooks being sent to the
region silos.
Finally, because we want to forward ALL webhooks to Codecov, that
means we're forwarding installation events, a webhook that in Sentry
gets processed in the control silo, so that gets its own mailbox