github source: reason and CI-branch guardrails - #283
Open
constkolesnyak wants to merge 1 commit into
Open
Conversation
- allow_reasons/deny_reasons filter on GitHub's notification reason (deny comment/subscribed keeps mentions and review requests while dropping watch churn) - deny_ci_branches drops workflow-run noise on branches that aren't yours (deny-only: ci_branch is empty for non-CI notifications, so an allow list would fail closed and drop the whole feed) - InboxFilter.rejects() + capped per-record drop logging so a vanished notification can be traced to the rule that ate it Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
4 tasks
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
What
Extends the existing GitHub inbox guardrails with two more
FieldRules, in the same idiom as the currentrepo_name/actorsrules:sync.github.allow_reasons/deny_reasons— match on GitHub's own notificationreason(mention,review_requested,subscribed,comment,ci_activity, …).sync.github.deny_ci_branches— match onci_branch, the branch parsed out of a CheckSuite title.Also logs which rule dropped a record, so a silent inbox is diagnosable instead of guesswork.
Why
The existing repo/actor guardrails are all-or-nothing per repo. On a busy repo the two dominant noise sources are:
subscribed/commentnotifications follow for every subsequent reply. Denying those keeps mentions, review requests and activity on your own PRs while dropping the follow-up stream.mainproduce CheckSuite notifications that are never actionable for a contributor. Denyingmain/masterkeeps CI failures on your own PR branches.Doing either today means denying the whole repo, which also loses the mentions you actually wanted.
Notes
deny_ci_branchesis deny-only on purpose.ci_branchis empty for every notification that isn't a CheckSuite, so a non-empty allow list would be fail-closed and would drop the entire feed. That asymmetry is documented in bothconfig.pyanddocs/sources.md.Empty lists everywhere = current behaviour, so this is a no-op for existing configs.
Testing
tests/test_github_ci_branch.py(new) covers CheckSuite branch parsing and the deny path;tests/test_source_filters.pygains reason-rule cases. Verified behaviour of the composed filter:reason=mentionreason=review_requestedreason=subscribedreason=ci_activity, ci_branch=mainreason=ci_activity, ci_branch=feat/xRunning in my fork against a live GitHub feed.