eps1lon / actions-label-merge-conflict

GitHub action that adds a label once a PR has merge conflicts

I maintain stuff

actions-label-merge-conflict's Issues

Add custom notification mechanism

Thanks a lot for your Github action; it is mighty!

I wanted to ask if we can have custom mechanisms for notifying these results to the respected developers (Author and reviewers if possible) via different means (Like email, slack, or any other thing).

Currently, the only way to notify the author is via email (after the bot comment).

It will be fantastic also when the author fixes the PR => To notify the reviewers in this PR, i.e. commentOnClean

Either we can have our own custom commentOnClean and commentOnDirty actions, or you can share the result from your action to use it in a different job or step to do custom notification!

Thanks a lot @eps1lon

Mark comment as outdated once conflict resolved

When a big PR (e.g. a formatting PR like mdn/content#24062) gets stalled for a while, a lot of duplicate comments pile up. It would be great if the comment can be minimized each time the conflict is resolved.

`continueOnMissingPermissions` should continue when `repoToken` is missing?

Perhaps continueOnMissingPermissions should continue when repoToken is missing?

The end purpose is to prevent this action from running on forks since that doesn't make sense in many use cases. Setting continueOnMissingPermissions does this and allows for exceptions where necessary permissions can be granted.

However, when the main repo uses MY_SPECIAL_TOKEN instead of something that exists in every repo, then the failure is missing input not missing permissions. I think continueOnMissingPermissions should handle this as if it were missing permissions and fail gracefully. The permissions are evidently missing in that case too!

Misconfiguration or does this action waste a lot of CI time (and money)?

Hey,

first of all this is a really great action so I'm definitely grateful.

One thing I noticed though is that in our repository, where we currently have about 20 open PRs this action runs on every PR and it does so for about 10 minutes.

That is a lot of CI time wasted just for adding a label, so I'm wondering if I misunderstood or misconfigured the action maybe?
Or is this just the nature of it? I definitely don't mean to complain, just trying to understand.

- name: Check if PR branch has conflicts
        uses: eps1lon/actions-label-merge-conflict@releases/2.x
        with:
          repoToken: ${{ secrets.GITHUB_TOKEN }}
          dirtyLabel: 'pr: conflicted'
          removeOnDirtyLabel: 'pr: conflicted'

Dependency Dashboard

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• chore(deps): update dependency typescript to v5.4.5

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• chore(deps): update dependency @types/node to v20.12.7

Detected dependencies

github-actions

.github/workflows/ci.yml

• actions/checkout v4
• actions/setup-node v4

npm

package.json

• @actions/core 1.10.1
• @actions/github 6.0.0
• @types/node ^20.11.30
• @vercel/ncc 0.38.1
• prettier 3.2.5
• typescript 5.4.3

---

• Check this box to trigger a request for Renovate to run again on this repository

Duplicate comment

In FreeTubeApp/FreeTube#2722 the workflow bot posted a duplicate comment

I had this happen multiple times before

add label back when conflicts are resolved if the label was removed

When removeOnDirtyLabel removes the label it doesnt add the label back when the conflicts are resolved. It would be nice for the workkflow to do that also.

If the label wasn't present when the conflicts occurred the workflow doesn't have to apply a label.

No label added

I added the example code in a new .yml file in the .github/workflows folder.
The job is displayed in the pull requests, but always finishes successfully after 1 second, but there are definitely merge conflicts to the base branch.
I know this description is quite vague but maybe somebody has a idea what i am doing wrong

Workflow doesn’t run on pull request when pull request is created by another workflow action and have conflict

I have 2 workflow file.
One is test.xml and other is merge.xml

The test.xml run php unit test and if the test successful it will create a pull request to staging branch (the test.xml run in feature branch).

The strange is, if the pull request have conflict, the merge.xml workflow will not triggered. But when the pull request don't have any conflict, it will run and merge the pull request. Did my xmls are misconfiguration?

Here is the xmls.

Test.xml

name: Test
on:
  push:
    branches-ignore:
      - staging
jobs:
  run-test:
    runs-on: self-hosted
    steps:
       - name: run test
  pullrequest-to-staging:
    needs: [run-test]
    runs-on: self-hosted
    steps:
      - name: Checkout current branch
        uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - name: Create Pull Request to staging
        uses: repo-sync/pull-request@v2
        with:
          github_token: ${{ secrets.BOT_TOKEN }}
          pr_title: "Pulling ${{ steps.branch_name.outputs.branch }} into staging"
          pr_body: ":crown: *An automated PR*"
          destination_branch: "staging"
          pr_label: "automerge"

merge.xml

name: merge-to-staging
on:
  pull_request:
    branches:
      - staging
jobs:
  merge-to-staging:
    runs-on: self-hosted
    steps:
      - name: Label merge conflicts
        uses: eps1lon/[email protected]
        with:
          repoToken: "${{ secrets.BOT_TOKEN }}"
          dirtyLabel: "conflicts"
          continueOnMissingPermissions: true
      - name: Merge to staging
        uses: pascalgn/[email protected]
        env:
          GITHUB_TOKEN: "${{ secrets.BOT_TOKEN }}"

Please add LINCENSE file

https://github.com/eps1lon/actions-label-merge-conflict/blob/main/package.json#L3

The package.json shows that this action is published under MIT license but there is no LICENSE file in the root folder.
Could you add a LICENSE file?

Node.js 16 actions are deprecated

Use of this action is now warning:

Node.js 16 actions are deprecated. Please update the following actions to use Node.js 20: eps1lon/actions-label-merge-conflict@releases/2.x. For more information see: https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/.

Missing release for comment feature to work

Hey @eps1lon
It seems you forgot to release (tag) since the merge of the pull request.
v1.4.0...main
Can you release 1.5.0 please? Thanks!

Mark previous `commentOnDirty` comments as "outdated"

GitHub allows to "hide" comments, choosing between a couple of different reasons. "Outdated" or "resolved" would be fitting to hide commentOnDirty comments once the conflicts are resolved. This really helps with the readability of long PRs.

This would be a really nice addition to this action :)

https://docs.github.com/en/free-pro-team@latest/graphql/reference/mutations#minimizecomment

Option to throttle the action

Hi, thanks for this very convenient action! We've been using it for a while at https://github.com/leanprover-community/mathlib (see here), but recently the action has been failing on every run with the error:

Error: GraphqlError: API rate limit exceeded for user ID XXXX.
Error: API rate limit exceeded for user ID XXXX.

I suspect this is because we have a large number of open PRs (565 at the moment, but we're steadily approaching 600) and the action is making a large number of API calls in a short period of time.

Would it be possible to add an option to throttle the rate of calls somehow so that we can keep using your action? Thanks!

More meaningful error message if commenting fails, and perhaps retry

Recently, running the workflow failed in our repo, see the workflow output, with the following error:

Error: error adding "This pull request has merge conflicts. Please resolve those before requesting a review.": HttpError: invalid json response body at https://api.github.com/repos/Lombiq/Open-Source-Orchard-Core-Extensions/issues/291/comments reason: Unexpected end of JSON input
    at /home/runner/work/_actions/eps1lon/actions-label-merge-conflict/9[29](https://github.com/Lombiq/Open-Source-Orchard-Core-Extensions/actions/runs/3554453936/jobs/5970562928#step:3:31)24ba33a60e436034b0ac3838de523bf7df071/dist/index.js:7594:23
    at Generator.throw (<anonymous>)
    at rejected (/home/runner/work/_actions/eps1lon/actions-label-merge-conflict/92924ba33a60e436034b0ac3838de523bf7df071/dist/index.js:7364:65)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

I suspect this was due to a temporary issue with the GitHub web API, because re-running the workflow succeeded, and the action perfectly updated only those PRs that needed it.

My request would be to please consider adding a more meaningful error message in such cases, e.g. (if this is indeed a GH API error) something along the lines of "Error: error adding "This pull request has merge conflicts. Please resolve those before requesting a review." due to an invalid response from the GitHub API. This is most possibly just a temporary issue; try re-running the action. Don't worry, it won't duplicate labels or comments."

Ideally, there would also be some retry logic, so the action would back off for like a second, then try again, then back off for 3 second and try again, and if that still fails, then fail with an error message like "Error: error adding "This pull request has merge conflicts. Please resolve those before requesting a review." due to an invalid response from the GitHub API, even after 3 attempts. This is most possibly just a temporary issue; try re-running the action in a few minutes. Don't worry, it won't duplicate labels or comments."

Feature request: Filter by author

Hi, thank you for this Action, it's really useful for me! I'm using it to help automate Dependabot changelogs.
It would be great if I could make it only look at PRs opened by certain authors (in my case, Dependabot). Is that possible?

This is my use case, basically this Action just needs to leave a comment on Dependabot pull requests to tell it to recreate the PR: https://github.com/UniversalMediaServer/UniversalMediaServer/blob/cd219026f348853c4bcb1e971160af54c352a90a/.github/workflows/pull-request-conflict.yaml and that works along with this step https://github.com/UniversalMediaServer/UniversalMediaServer/blob/cd219026f348853c4bcb1e971160af54c352a90a/.github/workflows/ci.yaml#L258-L275 which updates the changelog in the Dependabot PRs

Changes requested

Hi @eps1lon,

First of all i want to thankyou for this amazing workflow.
I know this is a very very very low priory and not even in the scope of this workflow but i had to ask.

Is it possible for u to create this workflow with changes requested?
It would be almost the same as the current workflow.

The workflow only needs to know if there are requested changes on a PR -> add label -> on new commits -> remove label

If we look at https://github.com/eps1lon/actions-label-merge-conflict#example-usage
U can remove commentOnDirty and commentOnClean because that is not necessary

Now u have

on:
  push:
  pull_request_target:
    types: [synchronize]

Needs to be

on:
  pull_request_review:
    types: [submitted]
  pull_request_target:
    types: [synchronize]

request changes in PR with merge conflicts

The ultimate goal is to send notifications to a user. I hoped that adding labels does the trick but it doesn't.

Seems like we have to fallback to comments anyway. I think reviews are a good place for that since they're dismissable. But simple comments might be sufficient (though harder to query).

Initial idea for a query leveraging reviews:

query { 
  repository(owner:"mui-org", name:"material-ui") { 
    pullRequests(states:OPEN,first:100) {
      nodes {
        reviews(author:"eps1lon",states:CHANGES_REQUESTED) {
          nodes {
            id
          }
        }
      }
    }
  }
}

If the PR is mergable dismiss this review. Otherwise add a review requesting changes.

GITHUB_TOKEN permissions used by this action

At https://github.com/step-security/secure-workflows we are building a knowledge-base (KB) of GITHUB_TOKEN permissions needed by different GitHub Actions. When developers try to set minimum token permissions for their workflows, they can use this knowledge-base instead of trying to research permissions needed by each GitHub Action they use.

Below you can see the KB of your GITHUB Action.

name: "Label Conflicting Pull Requests"
github-token:
  action-input:
    input: repoToken
    is-default: false
  permissions:
    pull-requests: write
    pull-requests-reason: to label PRs
#Reference: https://github.com/eps1lon/actions-label-merge-conflict/blob/a2389f3d584f2f820277e63d9b7310622657a887/sources/main.ts#L333

If you think this information is not accurate, or if in the future your GitHub Action starts using a different set of permissions, please create an issue at https://github.com/step-security/secure-workflows/issues to let us know.

This issue is automatically created by our analysis bot, feel free to close after reading :)

References:

GitHub asks users to define workflow permissions, see https://github.blog/changelog/2021-04-20-github-actions-control-permissions-for-github_token/ and https://docs.github.com/en/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token for securing GitHub workflows against supply-chain attacks.

Setting minimum token permissions is also checked for by Open Source Security Foundation (OpenSSF) Scorecards. Scorecards recommend using https://github.com/step-security/secure-workflows so developers can fix this issue in an easier manner.

The set-output command is deprecated and will be disabled soon

The set-output command is deprecated and will be disabled soon.

We are using this workflow in one of our actions in this action. This action is referenced in our projects and it generates the warning for example on line 31 under Check for Merge Conflict in PR in the jobs.

This issue already has a pull request, I just want to ensure it is not missed.