This action intuitively checks open pull request(s) for merge conflicts and marks them with a label and optionally leaves a comment to alter the author.

Work by Geek & Poke: Being A Coder Made Easy (CC BY 3.0) just shorter.

You'll need to manually create a label through GitHub. This can be done through the UI if you so with.

name: Auto Label Conflicts
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

permissions: # Optional: minimum permission required to add labels or comments
  issues: write
  pull-requests: write

jobs:
  auto-label:
    runs-on: ubuntu-latest
    steps:
      - uses: prince-chrismc/label-merge-conflicts-action@v1
        with:
          conflict_label_name: "has conflict"
          github_token: ${{ secrets.GITHUB_TOKEN }}
          # These are optional incase you need to adjust for the limitations described below
          max_retries: 5
          wait_ms: 15000
          detect_merge_changes: false # or true to handle as conflicts
          conflict_comment: ":wave: Hi, @${author},\n\nI detected conflicts against the base branch. You'll want to sync :arrows_counterclockwise: your branch with upstream!"
          # The `${author}` will be replaced with the username of who ever opened the pull requestion, this can be omitted
          # Ommiting `conflict_comment` will disable commenting, only a label will be applied

1. GitHub does not reliably compute the mergeable status which is used by this action to detect merge conflicts.
   • If the base branch, such as main, changes the mergeable status is unknown until someone (most likely this action) requests it. GitHub then tries to compute the status with an async job.
   • This is usually quick and simple, but there are no guarantees and GitHub might have issues. You can tweak max_retries and wait_ms to increase the timeout before giving up on a Pull Request.
2. GitHub does not run actions on pull requests which have conflicts
   • When there is a conflict it prevents the merge commit from being calculated. See this thread.
   • This is required for the mergeable as per the API documentation

When merging a pull request, no matter the strategy, there may inadvertently be changes (i.e git blobs which over lap and need to be recombined) which can have negative side effects. For example...

I was working on an app with a friend and [...] I ran git pull. There were no merge conflicts, but git added duplicate functions to a file after merge. I spent an hour trying to figure our what the problem was before realizing that git had made a mistake while merging. ref

ℹ️ This is a rapidly changing topic. Feel free to open an issue if there's any problems.

If a user without write access opens a 'Pull Request' from their fork then GitHub will not be granted adequate permissions to set the labels details here. Hence the not accessible error. Try the following steps:

• using the (potentially dangerous) event pull_request_target
• setting the workflow permissions provided in the example.

It boils down to the GitHub Action's permissions current behavoir. The default permissions for any event type is read only. The default can be adjusted for the repository or set for each workflow explicitly. However, as per the documentation...

Pull requests from public forks are still considered a special case and will receive a read token regardless of these settings.

See actions/labeler#12, actions/first-interaction#10, and Actions are severely limited for more information and some history on the issue.