Incorrectly merging when `PR is probably ready: mergeable_state: undefined`
hongaar opened this issue · comments
The action merged some pull requests while checks where still failing and/or required reviews were missing. This is an example output:
INFO Event name: status
INFO Skipping PR update, required label missing: please-rebase
INFO Merging PR #142 feat: validate content type
INFO PR is probably ready: mergeable_state: undefined
INFO PR successfully merged!
INFO Removed labels: [ { id: 1936467964,
node_id: 'MDU6TGFiZWwxOTM2NDY3OTY0',
url:
'https://api.github.com/repos/exivity/proximity/labels/automerge',
name: 'automerge',
color: 'ededed',
default: false,
description: null } ]
These are the checks for last commit on the merged branch (in this example, there was also a required review missing):
And here is the full workflow:
name: automerge
on:
pull_request:
types:
- labeled
- unlabeled
- synchronize
- opened
- edited
- ready_for_review
- reopened
- unlocked
pull_request_review:
types:
- submitted
check_suite:
types:
- completed
status: {}
jobs:
automerge:
runs-on: ubuntu-latest
steps:
- name: automerge
uses: pascalgn/automerge-action@v0.8.0
env:
GITHUB_TOKEN: "${{ secrets.GITHUB_PAT }}"
MERGE_LABELS: "automerge"
MERGE_REMOVE_LABELS: "automerge"
MERGE_METHOD: "squash"
MERGE_COMMIT_MESSAGE: "pull-request-description"
MERGE_FORKS: "false"
UPDATE_LABELS: "please-rebase"
UPDATE_METHOD: "rebase"
This looks like a duplicate of #61. Could you check if the information in that issue might help you?
Generally speaking, I only see two possibilities for this behaviour:
- This action just calls the GitHub API to merge, so it could be a problem in the API itself, causing PRs to be merged even though they should not. I find this highly unlikely, but if you suspect that this might be the cause, you need to contact GitHub support directly
- A wrong configuration. See #61. Possibly, the user from the "GITHUB_PAT" token is an administrator and is excluded from certain rules
@pascalgn thanks for your response. Decreasing the access level for the user who issued the PAT (our bot user) seems to have solved the issue, so your second point was indeed the reason we were seeing this.
To help others with this, would you accept a PR describing this behaviour in the Limitations section of the readme?
Yes, that should be fine!