pascalgn / automerge-action

GitHub action to automatically merge pull requests that are ready
MIT License
850 stars 207 forks source link

Merges PRs when mergeable_state = undefined #234

Open Nek-12 opened 1 year ago

Nek-12 commented 1 year ago
Run pascalgn/automerge-action@v0.15.6
  env:
    GITHUB_TOKEN: ***
    MERGE_LABELS: automerge,!wip
    MERGE_FORKS: false
    MERGE_READY_STATE: clean
INFO  No update done due to PR mergeable_state unstable
INFO  Merging PR #97 Fixes to challenges + performance
INFO  PR is probably ready: mergeable_state: undefined // <- ??
INFO  PR successfully merged!
INFO  Action result: [ { mergeResult: 'merged', pullRequestNumber: 97 } ]
INFO  More than one result, using  first result for action output

This seems like a bug. This automerge action started after a non-required workflow (one of several) has finished execution. I don't think we should merge prs that have an undefined state because I specified the "clean" state explicitly. I'm using PAT to run the action with admin rights.

Bombarding commented 1 year ago

Hello @Nek-12, so I was having this problem as well, and i managed to get this working based off of #170 This was my original CI in a single workflow file.

graph LR;
A[create pr]-->B[approve pr];
B-->C[merge pr]

So, when doing it this way (something I was unable to solve) I got the same undefined state that you are seeing. Despite PR status checks passing.. it was unable to verify that it was in a merge ready state and was merging before PR checks completed, which I did not want

Automerge action was removed from ci.yml and put it its own automerge.yml

---
name: Auto Merge Pull Request With Approved Label
on:
  repository_dispatch:
    types: [ ready-to-merge ] # This was the main fix
jobs:
  auto-merge:
    name: Auto Merge The Created Pull Request
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write
    steps:
      - id: automerge
        name: automerge
        uses: pascalgn/automerge-action@v0.15.6
        env:
          GITHUB_TOKEN: ${{ secrets.SECRET_TOKEN }} # PAT
          MERGE_LABELS: "automerge,autogenerated"
          MERGE_METHOD: "merge"

Then, I have a pull-request-checks.yml which is loosely Trivy Scan, and Spin up the container from GHCR. Adding in the following code, allowed me to solve this:

  repo-event:
    name: Set Repository Event
    permissions:
      contents: write
    runs-on: ubuntu-latest
    needs: [trivy-scan, compose-container]
    steps:
      - name: Repository Dispatch
        uses: peter-evans/repository-dispatch@v2
        with:
          token: ${{ secrets.GITHUB_TOKEN }}
          event-type: ready-to-merge
          client-payload: '{"github": ${{ toJson(github) }}}'
        if: github.event_name == 'pull_request'

So... Repository Dispatch by peter evens, will create an event called ready-to-merge using ${{ secrets.GITHUB_TOKEN }} with contents: write permissions. Because that has a needs: [job1, job2] it will not create the event until those PR checks pass. Once that event is created, using

on:
  repository_dispatch:
    types: [ ready-to-merge ]

Will force the automerge action to kick off. Because the action does not natively wait for any PR checks to pass, approval, or statuses at this point (since those requirements are already done), it recognizes that and merges. You can use MERGE_READY_STATE: 'clean' if you want, but setting up the action in this manor basically says that the creation of the repository_dispatch == MERGE_READY_STATE: 'clean'. Force setting the MERGE_READY_STATE is redundant, as using the repository_dispatch event nets the following output when pascalgn's action is run. image

Nek-12 commented 1 year ago

Thanks @Bombarding for such a detailed workaround. Yes, a custom trigger action will definitely work. I'll copy your config :)