Add merge conflict detector workflow

[yashgoyal0110]

What kind of change does this PR introduce?

feature

fixes: #4892

Snapshots/Videos:

If relevant, did you update the documentation?

Summary

Does this PR introduce a breaking change?

Checklist

CodeRabbit AI Review

• I have reviewed and addressed all critical issues flagged by CodeRabbit AI
• I have implemented or provided justification for each non-critical suggestion
• I have documented my reasoning in the PR comments where CodeRabbit AI suggestions were not implemented

Test Coverage

• I have written tests for all new changes/features
• I have verified that test coverage meets or exceeds 95%
• I have run the test suite locally and all tests pass

Other information

Have you read the contributing guide?

Summary by CodeRabbit

• Chores
  • Improved CI/CD tooling for merge conflict detection.

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

[github-actions]

Our Pull Request Approval Process

This PR will be reviewed according to our:

1. Palisadoes Contributing Guidelines

2. AI Usage Policy

Your PR may be automatically closed if:

1. Our PR template isn't filled in correctly

2. You haven't correctly linked your PR to an issue

Thanks for contributing!

[coderabbitai]

Walkthrough

Adds a new GitHub Actions workflow configuration file that automatically detects unresolved merge conflicts in pull requests when the base branch is updated. The workflow triggers on pull request events and pushes to main or develop branches, delegating conflict detection to a reusable workflow from an external repository.

Changes

Cohort / File(s)	Summary
GitHub Actions Workflow Configuration .github/workflows/merge-conflict-detector.yml	Introduces new workflow triggered on pull_request_target (opened, reopened, synchronize, ready_for_review) and push events to main/develop. Reuses external merge-conflict-detector workflow from PalisadoesFoundation/.github repository.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The PR description lacks critical information: the summary section is empty, motivation/problem explanation is missing, breaking change implications are not addressed, and the provided context suggests the issue is #4892 but lacks detail.	Complete the summary section explaining the motivation and problem being solved; provide details about what the workflow does and why it's needed; clarify any breaking changes or testing requirements.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Add merge conflict detector workflow' accurately describes the main change in this PR—adding a new GitHub Actions workflow for merge conflict detection.
Linked Issues check	✅ Passed	The PR successfully implements the objective from issue #4892 by adding the merge conflict detector workflow that reuses the existing implementation from the .github repository.
Out of Scope Changes check	✅ Passed	All changes in this PR are within scope—a single new workflow file (.github/workflows/merge-conflict-detector.yml) is added for the intended merge conflict detection functionality.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

---

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.}

[yashgoyal0110]

@palisadoes
Shard 8 is failing in CI.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 95.16%. Comparing base (b74f5f0) to head (2de7da4).
⚠️ Report is 34 commits behind head on develop.

Additional details and impacted files

@@             Coverage Diff             @@
##           develop    #4907      +/-   ##
===========================================
- Coverage    95.32%   95.16%   -0.17%     
===========================================
  Files          899      905       +6     
  Lines        76472    77000     +528     
  Branches     10746     9062    -1684     
===========================================
+ Hits         72899    73275     +376     
- Misses        3573     3725     +152     

Flag	Coverage Δ
install	71.21% <ø> (?)
integration	94.70% <ø> (ø)
unit	98.85% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 6 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[palisadoes]

1. Why is this being applied on pushes?
2. I just noticed the same on the centralized GTA.
3. We only want the person who submitted the PR to know about conflicts specific to their PR. From what I remember, that's not possible using the push action

[yashgoyal0110]

@palisadoes
This workflow has two seperate jobs.
One works for push on base, which marks PR as conflicted (if any).
And another works for respective PR only

[yashgoyal0110]

@palisadoes
is anything else need to be addressed here?

[palisadoes]

@palisadoes This workflow has two seperate jobs. One works for push on base, which marks PR as conflicted (if any). And another works for respective PR only

@yashgoyal0110

I apologize for not responding earlier. I've been looking at this some more and have some additional questions as I have been focusing more on app features and testing PRs.

1. Who gets notified if there is a conflict on the push? Is it all PR authors for the repository, or just those that have PRs with conflicting files?
   1. How are they notified? Is it the regular email system?
2. Why did you put both push and PR workflows in the same file? I'd think it would be better to separate them as we use generally one file per workflow type to help with maintainability.

[yashgoyal0110]

@palisadoes This workflow has two seperate jobs. One works for push on base, which marks PR as conflicted (if any). And another works for respective PR only

@yashgoyal0110

I apologize for not responding earlier. I've been looking at this some more and have some additional questions as I have been focusing more on app features and testing PRs.

1. Who gets notified if there is a conflict on the push? Is it all PR authors for the repository, or just those that have PRs with conflicting files?

   1. How are they notified? Is it the regular email system?

2. Why did you put both push and PR workflows in the same file? I'd think it would be better to separate them as we use generally one file per workflow type to help with maintainability.

only those with conflicting files get notified. they are notified through email as workflow fails.
we can separate them (if required/needed) as we have two different jobs serving the purpose.

[yashgoyal0110]

@palisadoes
any feedbacks?

[yashgoyal0110]

@palisadoes
any feedbacks?

[palisadoes]

@palisadoes This workflow has two seperate jobs. One works for push on base, which marks PR as conflicted (if any). And another works for respective PR only

@yashgoyal0110
I apologize for not responding earlier. I've been looking at this some more and have some additional questions as I have been focusing more on app features and testing PRs.

1. Who gets notified if there is a conflict on the push? Is it all PR authors for the repository, or just those that have PRs with conflicting files?

   1. How are they notified? Is it the regular email system?

2. Why did you put both push and PR workflows in the same file? I'd think it would be better to separate them as we use generally one file per workflow type to help with maintainability.

only those with conflicting files get notified. they are notified through email as workflow fails. we can separate them (if required/needed) as we have two different jobs serving the purpose.

1. Please separate the jobs to that it's easier to maintain in the long term.

2. It'll need to be fixed in the .github issue too. It's reopened.

3. Name the files:

   .github/workflows/push-merge-conflict-detector.yml
   .github/workflows/pull-request-merge-conflict-detector.yml
   

4. You don't need to specify the type of pull-request-target. By default it should run on all types.

[yashgoyal0110]

@palisadoes This workflow has two seperate jobs. One works for push on base, which marks PR as conflicted (if any). And another works for respective PR only

@yashgoyal0110
I apologize for not responding earlier. I've been looking at this some more and have some additional questions as I have been focusing more on app features and testing PRs.

1. Who gets notified if there is a conflict on the push? Is it all PR authors for the repository, or just those that have PRs with conflicting files?

   1. How are they notified? Is it the regular email system?

2. Why did you put both push and PR workflows in the same file? I'd think it would be better to separate them as we use generally one file per workflow type to help with maintainability.

only those with conflicting files get notified. they are notified through email as workflow fails. we can separate them (if required/needed) as we have two different jobs serving the purpose.

1. Please separate the jobs to that it's easier to maintain in the long term.
2. It'll need to be fixed in the .github issue too. It's reopened.
3. Name the files:

   .github/workflows/push-merge-conflict-detector.yml
   .github/workflows/pull-request-merge-conflict-detector.yml
   

4. You don't need to specify the type of pull-request-target. By default it should run on all types.

sure

[palisadoes]

Are you still working on this?

[yashgoyal0110]

Are you still working on this?

Yes

[github-actions]

This pull request did not get any activity in the past 10 days and will be closed in 360 days if no update occurs. Please verify it has no conflicts with the develop branch and rebase if needed.

[github-actions]

This pull request did not get any activity in the past 10 days and will be closed in 360 days if no update occurs. Please verify it has no conflicts with the develop branch and rebase if needed.

[github-actions]

This pull request did not get any activity in the past 10 days and will be closed in 360 days if no update occurs. Please verify it has no conflicts with the develop branch and rebase if needed.

[github-actions]

This pull request did not get any activity in the past 10 days and will be closed in 360 days if no update occurs. Please verify it has no conflicts with the develop branch and rebase if needed.

[github-actions]

This pull request did not get any activity in the past 10 days and will be closed in 360 days if no update occurs. Please verify it has no conflicts with the develop branch and rebase if needed.