Problem
When a detected conflict involves a PR authored by a bot or GitHub App (e.g., dependabot, renovate, github-actions[bot]), the current behavior creates awkward situations:
- Slack notifications mention bots with
@bot-username, which doesn't make sense
- PR comments are posted on bot PRs asking them to coordinate with humans
- Issue reports list bots as people who need to coordinate
- Humans are asked to "coordinate with a bot", which is unclear guidance
Common bot scenarios
- Dependabot PR conflicts with human PR - User needs to know their PR conflicts with a dependency update, but dependabot doesn't need to coordinate
- Two bot PRs conflict (e.g., dependabot + renovate) - Neither bot can coordinate; humans should be aware but different handling needed
- GitHub Actions bot PRs - Auto-generated PRs from workflows
Suggested solutions
Option 1: Filter out bot-authored PRs entirely
Add a configuration option to exclude PRs authored by bots:
env:
EXCLUDE_BOT_PRS: "true" # Skip any PR authored by a bot
Pros:
- Simple to implement and understand
- Reduces noise from dependency update conflicts
Cons:
- Users might want to know when their PR conflicts with a bot PR
- Loses visibility into important conflicts
Option 2: Asymmetric handling (recommended)
When a conflict involves one bot PR and one human PR:
- ✅ Notify the human author only (Slack, PR comment)
- ❌ Don't notify or comment on the bot PR
- ✅ Include conflict in reports/issues but note it's a bot PR
When both PRs are bots:
- ❌ Skip Slack notifications and PR comments
- ✅ Include in reports for visibility
- Note: "Both PRs are automated - review dependency/automation conflicts"
Option 3: Configurable bot list
Allow users to specify which bots to filter:
env:
EXCLUDE_BOT_AUTHORS: "dependabot[bot],renovate[bot],github-actions[bot]"
Pros:
- Flexible - users control which bots to exclude
- Can exclude some bots but not others
Cons:
- Requires users to know bot usernames
- Maintenance burden to keep list updated
Option 4: Auto-detect using GitHub's bot flag
Use GitHub API's user.type field to detect bots automatically:
if pr.user.type == 'Bot':
# Handle differently
Pros:
- No configuration needed
- Automatically handles all bots
- Future-proof for new bots
Cons:
- Relies on GitHub API correctly flagging bots
Recommended implementation
Combination of Option 2 + Option 4:
- Auto-detect bots using GitHub API's
user.type field
- Apply asymmetric handling:
- Human vs Bot conflict: Notify human only, skip bot notifications
- Bot vs Bot conflict: Skip all notifications, include in reports with note
- Add optional override config:
EXCLUDE_BOT_PRS: "false" # Default: include bot PRs but handle smartly
TREAT_AS_BOTS: "custom-automation-user" # Additional usernames to treat as bots
Implementation details
-
Add bot detection in pr_data.py:
@dataclass
class PRInfo:
number: int
title: str
author: str
is_bot: bool # New field
-
Update conflict categorization in pr_conflict_detector.py:
# After deduplication, categorize conflicts
human_vs_human = [c for c in conflicts if not c.pr_a.is_bot and not c.pr_b.is_bot]
human_vs_bot = [c for c in conflicts if c.pr_a.is_bot ^ c.pr_b.is_bot]
bot_vs_bot = [c for c in conflicts if c.pr_a.is_bot and c.pr_b.is_bot]
-
Update notification modules:
slack_notify.py: Only send for human_vs_human, include human-only mention for human_vs_bot
pr_comment.py: Comment on human PR only for human_vs_bot conflicts
issue_writer.py: Include all conflicts but annotate bot PRs
-
Add summary output:
Found 45 conflicts:
- 30 human vs human conflicts
- 12 human vs bot conflicts (notifying humans only)
- 3 bot vs bot conflicts (report only, no notifications)
Additional considerations
Testing checklist
Priority
Medium - This is a quality-of-life improvement that reduces notification noise and prevents awkward bot mentions, but doesn't break existing functionality.
Problem
When a detected conflict involves a PR authored by a bot or GitHub App (e.g., dependabot, renovate, github-actions[bot]), the current behavior creates awkward situations:
@bot-username, which doesn't make senseCommon bot scenarios
Suggested solutions
Option 1: Filter out bot-authored PRs entirely
Add a configuration option to exclude PRs authored by bots:
Pros:
Cons:
Option 2: Asymmetric handling (recommended)
When a conflict involves one bot PR and one human PR:
When both PRs are bots:
Option 3: Configurable bot list
Allow users to specify which bots to filter:
Pros:
Cons:
Option 4: Auto-detect using GitHub's bot flag
Use GitHub API's
user.typefield to detect bots automatically:Pros:
Cons:
Recommended implementation
Combination of Option 2 + Option 4:
user.typefieldImplementation details
Add bot detection in
pr_data.py:Update conflict categorization in
pr_conflict_detector.py:Update notification modules:
slack_notify.py: Only send for human_vs_human, include human-only mention for human_vs_botpr_comment.py: Comment on human PR only for human_vs_bot conflictsissue_writer.py: Include all conflicts but annotate bot PRsAdd summary output:
Additional considerations
Bot PR comment wording: When commenting on a human PR about a bot conflict:
Slack message wording for human vs bot:
Testing checklist
user.typefieldPriority
Medium - This is a quality-of-life improvement that reduces notification noise and prevents awkward bot mentions, but doesn't break existing functionality.