ci: Add workflow to label PRs with merge conflicts

[xdustinface]

Just adds a workflow to label conflicting PRs.

Summary by CodeRabbit

• Chores
  • Implemented automated merge conflict detection for pull requests. Conflicted PRs are now automatically labeled and notified, encouraging contributors to rebase or merge changes before integration.

_{✏️ Tip: You can customize this high-level summary in your review settings.}

[coderabbitai]

Walkthrough

Introduces a GitHub Actions workflow that automatically detects and labels merge conflicts in pull requests. The workflow triggers on pushes to master and v\*-dev branches, and on pull request events, using a third-party action to flag conflicting PRs with metadata and informational comments.

Changes

Cohort / File(s)	Summary
Merge Conflict Detection Workflow \.github/workflows/conflict-check.yml``	New GitHub Actions workflow that detects merge conflicts, applies "merge-conflict" label to PRs, and posts comments instructing users to rebase or merge the base branch. Runs on pushes to master/v\*-dev branches and pull\_request\_target events.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~5 minutes

• Verify the workflow triggers on intended branches (master, v\*-dev)
• Confirm the eps1lon/actions-label-merge-conflict action is the correct and up-to-date version
• Review the label name and comment message for clarity and consistency with team conventions

Poem

🐰 A conflict-detecting friend now hops on in,
To catch those merges where the wars begin!
Labels and comments, all neat and clean,
The tidiest workflow you've ever seen! ✨

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the main change: adding a GitHub Actions workflow to label PRs with merge conflicts.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch ci/merge-conflict-label

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a1b027d and 4b174ff.

📒 Files selected for processing (1)

• .github/workflows/conflict-check.yml (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (19)

• GitHub Check: fuzz (dash_deserialize_address)
• GitHub Check: fuzz (hashes_sha512_256)
• GitHub Check: fuzz (dash_deserialize_block)
• GitHub Check: fuzz (hashes_cbor)
• GitHub Check: fuzz (hashes_ripemd160)
• GitHub Check: fuzz (hashes_sha256)
• GitHub Check: fuzz (hashes_sha512)
• GitHub Check: fuzz (hashes_json)
• GitHub Check: fuzz (hashes_sha1)
• GitHub Check: fuzz (dash_deserialize_script)
• GitHub Check: fuzz (dash_deserialize_amount)
• GitHub Check: fuzz (dash_deser_net_msg)
• GitHub Check: fuzz (dash_script_bytes_to_asm_fmt)
• GitHub Check: fuzz (dash_deserialize_witness)
• GitHub Check: fuzz (dash_outpoint_string)
• GitHub Check: Core Components Tests
• GitHub Check: RPC Tests (stable, true)
• GitHub Check: SPV Components Tests
• GitHub Check: Pre-commit (ubuntu-latest)

🔇 Additional comments (2)

.github/workflows/conflict-check.yml (2)

3-9: Verify that the push trigger works as intended with merge conflict detection.

The workflow triggers on both push events (to master and v*-dev) and pull_request_target events. While pull_request_target is appropriate for PR labeling, the push trigger may not provide the PR context needed for the merge conflict detection action to work correctly. Merge conflict checks are typically meaningful only for pull requests, not for direct pushes to base branches.

Clarify the intent:

• If the goal is to label existing PRs that become conflicted when commits land on base branches, verify that the action can detect and update PR labels when triggered by push events.
• If only PR-based conflict detection is needed, consider removing the push trigger.

---

17-22: Good use of third-party action with version pinning.

The action is correctly pinned to a specific version (v3), permissions are appropriately scoped to pull-requests: write, and the configuration uses only the standard GITHUB_TOKEN without exposing sensitive secrets. The label name and comment message are clear and helpful.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[PastaPastaPasta]

I think synchronize does all these

[PastaPastaPasta]

@coderabbitai is this true?

[coderabbitai]

🧩 Analysis chain

🌐 Web query:

GitHub Actions pull_request_target event types opened synchronize reopened

💡 Result:

Short answer

• The pull_request_target event supports the same pull-request activity types (opened, synchronize, reopened, plus others like labeled, edited, closed, etc.). By default workflows run for types opened, synchronize and reopened. [1][2]

Example (explicit types)
on:
pull_request_target:
types: [opened, synchronize, reopened]

Important notes

• pull_request_target runs in the context of the base branch (can access repo secrets) and will run even if the PR has merge conflicts — but it has security risks when running untrusted PR code. [1]
• If you omit types, GitHub defaults to opened, synchronize, reopened. [1][3]

Sources
[1] GitHub Actions — Events that trigger workflows (pull_request_target).
[2] GitHub Actions — Events that trigger workflows (pull_request).
[3] GitHub developer docs — PullRequestEvent (actions like opened, synchronize, reopened).

---

@PastaPastaPasta No, that's not true. opened, synchronize, and reopened are three distinct event types:

• opened: Triggers when a PR is first created
• synchronize: Triggers when new commits are pushed to an existing PR branch
• reopened: Triggers when a previously closed PR is reopened

For a merge conflict checker, you need all three to catch conflicts at different stages of the PR lifecycle.

Note: If you omit the types field entirely, GitHub defaults to [opened, synchronize, reopened], so you could simplify to:

pull_request_target:

But that's different from using only synchronize, which would miss conflicts on newly opened or reopened PRs.

[PastaPastaPasta]

LGTM pretty much the same as we have in core