Won't automerge the PR. HttpError: Unprocessable Entity: "Can not approve your own pull request"

[tairosonloa]

Hi! First thanks for your job. I'm facing a strange issue here that I cannot get rid of. I finally achieved to get the workflow running as it is creating a PR to Sync the repo. However, PR won't be automerged and the GitHub Actions will fail. I tried two different configs, with different errors:

Config 1:

jobs:
  sync:
    runs-on: ubuntu-latest

    steps:
      - uses: tgymnich/fork-sync@v1.4
        with:
          owner: mikecao
          token: ${{ secrets.GH_PERSONAL_TOKEN }} # with public repo access
          head: master
          base: production
          merge_method: merge
          pr_title: Fork Sync
          auto_approve: true

Error 1:

Run tgymnich/fork-sync@v1.4
  with:
    owner: mikecao
    token: ***
    head: master
    base: production
    merge_method: merge
    pr_title: Fork Sync
    auto_approve: true
request failed after 4 retries with a delay of 60
Error: Failed to create or merge pull request: HttpError: Unprocessable Entity: "Can not approve your own pull request"

---

Config 2:

jobs:
  sync:
    runs-on: ubuntu-latest

    steps:
      - uses: tgymnich/fork-sync@v1.4
        with:
          owner: mikecao
          token: ${{ secrets.GITHUB_TOKEN }} # not my personal token
          head: master
          base: production
          merge_method: merge
          pr_title: Fork Sync

Error 2:

Run tgymnich/fork-sync@v1.4
  with:
    owner: mikecao
    token: ***
    head: master
    base: production
    merge_method: merge
    pr_title: Fork Sync
    auto_approve: false
request failed after 4 retries with a delay of 60
Error: Failed to create or merge pull request: HttpError: Unprocessable Entity: "Can not approve your own pull request"

---

Do you know what could be the problem? If it is about a misconfiguration from my side, I will be happy to open a PR updating the documentation when I realize of my error.

Owner repo: https://github.com/mikecao/umami
My repo: https://github.com/tairosonloa/umami (you can see there some manually closed PR that the GitHub Action created while I was testing)

[tairosonloa]

I currently don't have any branch protection rules (although I plan to add them). It seems like with config 1, my user is creating and trying to approve the PRs, while with config 2 the PRs are being created and tried to be approved by github-actions bot.

Shouldn't it be different users as @R0Wi told in #24 ?

[R0Wi]

HI @tairosonloa if i remember correctly we introduced two new options in #24. One is the auto_approve option, the other one is the personal_token which i thing you're missing. So i think the user from token will open the PR while the user behind personal_token will auto approve it. Usually you will put the GitHub Actions token into token and some personal token with appropriate access (from another user) into personal_token and set auto_approve to true.

EDIT: just noticed that personal_token was removed from code in 99941e6. So it might be a bug then because a user who opened the PR cannot auto-approve it so i think we need two separate users here?

[tgymnich]

Both tokens have been merged into one in v1.4 to fix another issue. This might have broken the auto approve. Try using v1.3. For the time being.

[R0Wi]

@tgymnich if i can help somehow in fixing this just let me know 👍

[tairosonloa]

The following config is working, as you suggested:

jobs:
  sync:
    runs-on: ubuntu-latest

    steps:
      - uses: tgymnich/fork-sync@v1.3
        with:
          owner: mikecao
          github_token: ${{ secrets.GITHUB_TOKEN }}
          personal_token: ${{ secrets.GH_PERSONAL_TOKEN }}
          head: master
          base: production
          merge_method: merge
          pr_title: Fork Sync
          auto_approve: true

[nguyer]

Hi there. I see v1.5.0 is out now. Is it still recommended to use v1.3 if we're still running into this issue?

[tgymnich]

Yes v1.3 is still recommended for automerge when an approval is required. I still need to find the time to find out if there is an API to approve/merge your own PR when an approval is required. If there is no way I might even undo the changes up to v1.5

[R0Wi]

According to the discussion here https://gh.neting.ccmunity/t/do-not-require-owner-approval-if-the-pull-request-is-from-an-owner/369/66 it seems that reviewing/approving your own PR is currently not possible even if you're a code owner or admin.

I can remember that for repo admins there is a possibility to merge a PR even if required checks (like builds, reviews, ...) haven't been passed, yet. It's inside of the dropdown of the merge button. If there was an api for that we might could bypass all merge checks for the github action user. Unfortunately i didn't find anything in the docs https://docs.github.com/en/rest/reference/pulls#merge-a-pull-request so not sure if that's possible 😢

[tgymnich]

@R0Wi thanks for those insights. The next version of fork sync should probably then reintroduce the v1.3 behavior.

[elect86]

The following config is working, as you suggested:

jobs:
  sync:
    runs-on: ubuntu-latest

    steps:
      - uses: tgymnich/fork-sync@v1.3
        with:
          owner: mikecao
          github_token: ${{ secrets.GITHUB_TOKEN }}
          personal_token: ${{ secrets.GH_PERSONAL_TOKEN }}
          head: master
          base: production
          merge_method: merge
          pr_title: Fork Sync
          auto_approve: true

I did the very same, but the workflow still fails:

Error: Failed to create or merge pull request: HttpError: Resource not accessible by integration

And I have to merge it manually

[nguyer]

Error: Failed to create or merge pull request: HttpError: Resource not accessible by integration

I run into the same thing frequently on several different repos. Sometimes it works, sometimes it doesn't. I've basically just stopped using this action now because it is creating more chaos than it's solving.

[elect86]

Error: Failed to create or merge pull request: HttpError: Resource not accessible by integration

I run into the same thing frequently on several different repos. Sometimes it works, sometimes it doesn't. I've basically just stopped using this action now because it is creating more chaos than it's solving.

So now you are syncing manually?

[nguyer]

So now you are syncing manually?

For now, yes.

[tairosonloa]

I did the very same, but the workflow still fails:

Error: Failed to create or merge pull request: HttpError: Resource not accessible by integration

And I have to merge it manually

I suppose you are already set the GH_PERSONAL_TOKEN secret, right? If then, I remember I had some issues merging to the same branch on both upstream and forked. Dunno if that could help you.

[elect86]

I suppose you are already set the GH_PERSONAL_TOKEN secret, right? If then, I remember I had some issues merging to the same branch on both upstream and forked. Dunno if that could help you.

Yep, that's was the first thing in 1.4, under Settings -> Secrets -> Repository secrets

[JIAZHEN]

Hi @tairosonloa, how are you? Just wondering if you have any updates on this case?

[tgymnich]

I didn't get around fixing this yet. Using v1.3 is still the recommend way to solve this issue.

[JIAZHEN]

Many thanks for the reply. Look forward to the update in the later time :)

[tairosonloa]

Hi @tairosonloa, how are you? Just wondering if you have any updates on this case?

Still using 1.3, yep. Same config that #46 (comment)

[SebTM]

I'm still having this issue on v1.4 with this config: https://github.com/SebTM/YubiKey-Guide/blob/sync/.github/workflows/sync.yml
Did I missed something? TOKEN has permissions for public_repo

[tairosonloa]

I'm still having this issue on v1.4 with this config: https://github.com/SebTM/YubiKey-Guide/blob/sync/.github/workflows/sync.yml Did I missed something? TOKEN has permissions for public_repo

Read the issue before commenting @SebTM, please. Version 1.4 has this error. The solution is to use version 1.3 as I explained above, or use version 1.6 after PR #71 was merged.

[SebTM]

Thanks for the hint, I got into this especially as the README.md still show's v1.4 maybe this should be updated to a placeholder to look into releases what I missed - sorry!