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]

jobs:
  auto-label:
    runs-on: ubuntu-latest
    steps:
      - uses: prince-chrismc/label-merge-conflicts-action@v2
        with:
          conflict_label_name: "has conflict"
          github_token: ${{ github.token }}

          # --- Optional Inputs ---
          # To make sure the merge commit exactly matches the branch
          detect_merge_changes: false # or true to handle as conflicts
          # Omitting `conflict_comment` will disable commenting, only the label will be applied
          # The optional `${author}` will be replaced with the username of the pull request
          conflict_comment: |
            :wave: Hi, @${author},
            I detected conflicts against the base branch :speak_no_evil:
            You'll want to sync :arrows_counterclockwise: your branch with upstream!

1. GitHub does not reliably compute the mergeable status which is used by this action to detect merge conflicts. If the base branch (e.g. main) changes then the mergeable status is unknown until someone (like 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 the Pull Request.
2. GitHub does not run actions on pull requests which have conflicts - which will prevent this action from working. When there is a conflict it prevents the merge commit from being calculated. See this thread for more details. 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 an evolving 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 grant adequate permissions to set the labels (detailed here). Hence the not accessible error. Try the following steps:

• using the (potentially dangerous) event pull_request_target

• setting the workflow permissions by adding the minimum permission required to add labels or comments

  permissions:
    issues: write
    pull-requests: write

It boils down to the GitHub Action's permissions current behavior. 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.