Git Product home page Git Product logo

label-merge-conflicts-action's Introduction

Label Pull Requests with Merge Conflicts Automatically

MIT codecov

Purpose

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.

comic

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

Add it to Your Project

Create a Label

You'll need to decide on a label and manually create it if it does not already exist.

Setup a Workflow

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@v3
        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
          # By default a comment will be left, adding `conflict_comment: ''` will disable comments
          # 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!

Limitations

  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.

FAQ - What are Merge Changes?

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

FAQ - How do I fix "Resource not accessible by integration"?

ℹī¸ 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.

label-merge-conflicts-action's People

Contributors

dependabot[bot] avatar github-actions[bot] avatar prince-chrismc avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

label-merge-conflicts-action's Issues

Output if or which PRs have had labels added or removed

Some design here is needed.

I would like

  1. PRs which gain the label are moved to "In Progress" on my project board

I am not certain moving to "Review" would make sense when the label is removed but perhaps someone has a good use case where that is helpful.

Pull Requests who's changes have already been merged result in conflict

While testing #39 I noticed this with

https://api.github.com/repos/prince-chrismc/conan-center-index/pulls/22/files

[
  {
    "sha": "6390b5f44429a721fe918e8dba0e6feb8efab44f",
    "filename": "recipes/amqp-cpp/all/conandata.yml",
    "status": "modified",
    "additions": 6,
    "deletions": 0,
    "changes": 6,
    "blob_url": "https://github.com/prince-chrismc/conan-center-index/blob/6805ded7ac26b8ce6540c1c564af223f9de31bff/recipes/amqp-cpp/all/conandata.yml",
    "raw_url": "https://github.com/prince-chrismc/conan-center-index/raw/6805ded7ac26b8ce6540c1c564af223f9de31bff/recipes/amqp-cpp/all/conandata.yml",
    "contents_url": "https://api.github.com/repos/prince-chrismc/conan-center-index/contents/recipes/amqp-cpp/all/conandata.yml?ref=6805ded7ac26b8ce6540c1c564af223f9de31bff",
    "patch": "@@ -14,6 +14,9 @@ sources:\n   \"4.3.10\":\n     url: \"https://github.com/CopernicaMarketingSoftware/AMQP-CPP/archive/v4.3.10.tar.gz\"\n     sha256: \"4fa1e9650f7a08ae7217899431a3b3f0a173ad826dd819f0b8c760e4e2a65298\"\n+  \"4.3.11\":\n+    url: \"https://github.com/CopernicaMarketingSoftware/AMQP-CPP/archive/v4.3.11.tar.gz\"\n+    sha256: \"be2b11ada1020f77b859857310be54bd073c3a4f579d99a5e251a738576ca28c\"\n patches:\n   \"4.1.5\":\n     - patch_file: \"patches/0001-cmake-openssl-install-directories.patch\"\n@@ -30,3 +33,6 @@ patches:\n   \"4.3.10\":\n     - patch_file: \"patches/0001-cmake-openssl-install-directories.patch\"\n       base_path: \"source_subfolder\"\n+  \"4.3.11\":\n+    - patch_file: \"patches/0001-cmake-openssl-install-directories.patch\"\n+      base_path: \"source_subfolder\""
  },
  {
    "sha": "d3e2f2ec12bb96a884d34f311a24679f64566e15",
    "filename": "recipes/amqp-cpp/config.yml",
    "status": "modified",
    "additions": 2,
    "deletions": 0,
    "changes": 2,
    "blob_url": "https://github.com/prince-chrismc/conan-center-index/blob/6805ded7ac26b8ce6540c1c564af223f9de31bff/recipes/amqp-cpp/config.yml",
    "raw_url": "https://github.com/prince-chrismc/conan-center-index/raw/6805ded7ac26b8ce6540c1c564af223f9de31bff/recipes/amqp-cpp/config.yml",
    "contents_url": "https://api.github.com/repos/prince-chrismc/conan-center-index/contents/recipes/amqp-cpp/config.yml?ref=6805ded7ac26b8ce6540c1c564af223f9de31bff",
    "patch": "@@ -9,3 +9,5 @@ versions:\n     folder: all\n   \"4.3.10\":\n     folder: all\n+  \"4.3.11\":\n+    folder: all"
  }
]

https://api.github.com/repos/prince-chrismc/conan-center-index/commits/720c06d0d8ca481f0b9d03e3f42d92379da3eebd

"stats": {
  "total": 0,
  "additions": 0,
  "deletions": 0
},
"files": [

]

[feature] Context dependant querying

In order to keep a large number of pull requests update, not only on pushes to main but also to the head branches, the action needs to be run for different github.context.event. Querying all pull requests every single time is inefficient and it would be desirable to limit the runtime as much as possible.

The idea is to rely on the event type and payload in order to optimise the workflow.

  • push: check all pull requests
  • pull_request: check that specific pull request

Detect soft merge commit changes

TL;DR: Detect merge changes because conflict alone are insufficient

The problem arises when a PR can be merged (it has no conflicts), but it will create a new recipe revision when merged to master because it was not rebased. We cannot force a rebase before merging because there are so many changes in master that doesn't affect the PR and we don't want to trigger the CI for all the PRs after every merge. Github doesn't notify about this situation, the PR is perfectly mergeable and this is why we use Git, to be able to merge unrelated changes.

Our problem is that the merge might create an invalid recipe (and also the time it takes to build) even if it mergeable. To avoid these situations, usually, you can require a rebase/update before merging, and also the CI systems provide a branch indexing feature (Jenkins terminology) to trigger again the PR merging to master when the base branch changes. Again, we cannot trigger all the PRs for every commit in master and that's the reason why we need a custom solution.

The implementation should check the repository files and see if, after merging to master (at the moment just before clicking the merge button), the recipe revision computed in the PR is the same. If not, it should warn the user, or label the PR, or force-push a commit to the PR... wait for the build and try the merge again.

A Github action could do this job, adding labels like "This PR needs to be updated", our CI can check the label and ignore the PR... or trigger it again. This is different from the Conflicted label proposed here.

Originally posted by jgsogo in conan-io/conan-center-index#4725 (comment)

Consider removing the "This message is automatically generated.." note from comments

First off, thanks for this useful GitHub action!

The only (small) piece of feedback I'd have is to consider removing (or providing a way to turn off) this message when you configure conflict_comment:

***
This message is automatically generated by prince-chrismc/label-merge-conflicts-action so don't hesitate to report issues/improvements there.

https://github.com/prince-chrismc/label-merge-conflicts-action/blob/main/src/label.ts#L48-L50

While I understand the desire to point people back to this action's codebase (and to give you credit where credit is due), I feel the comment is sent to the wrong audience. Some novice developers/contributors may decide to click on the link in that message to ask questions about their merge conflict (or how to resolve the merge conflict they were notified about). The "automatically generated" message seems designed to be read by the lead developer(s), but in reality it may be sent to lower level developers or first time contributors who may not understand it's context.

Overall, it's a very minor quibble, I know. But, it stood out enough to me to create you an issue ticket. Feel free to just close this ticket though if you disagree. Thanks again!

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤ī¸ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.