limit processing to events we actually listen for #8
Conversation
by default, the webhook handler from django-github-app processes and stores all events, even if they are not registered as actionable. since the Pull Request event on GitHub sends many events we are not interested in: > Pull request assigned, auto merge disabled, auto merge enabled, closed, converted to draft, demilestoned, dequeued, edited, enqueued, labeled, locked, milestoned, opened, ready for review, reopened, review request removed, review requested, synchronized, unassigned, unlabeled, or unlocked. This causes floods of events in situations like python/cpython#132964 that we can skip processing for.
|
👀 This would actually be a good improvement to bring to django-github-app, I think. The project originally spun out of an internal service I wrote get around the limitation of the audit logs in GitHub only going back a few weeks. We had an API key leak by a contractor and my boss wanted audit logs around when the change was pushed, but it was outside the window of those few weeks. So really, initially it was written to store all events as an audit log. On top of that, I think my thought process was it was just simpler to store all events sent to the webhook -- the rationale also being if you subscribe to the event in the GitHub admin, we should store it. But my internal GitHub apps using django-github-app aren't quite on the scale of python/cpython 😄. Anyway, sorry for the random thought dump on your PR -- it came up on my main GitHub explore feed and got me thinking. |
by default, the webhook handler from django-github-app processes and stores all events, even if they are not registered as actionable.
since the Pull Request event on GitHub sends many events we are not interested in:
This causes floods of events in situations like python/cpython#132964 that we can skip the bulk of processing for.