Change:
runs-on: ubuntu-latest steps: - name: Resolving the merge commit <ins> env: GH_TOKEN: ${{ github.token }} </ins> run: | <del> if result=$(git ls-remote --exit-code ${{ github.event.pull_request.base.repo.clone_url }} refs/pull/${{ github.event.pull_request.number }}/merge 2>&1); then mergedSha=$(cut -f1 <<< "$result") echo "The PR appears to not have any conflicts, checking the merge commit $mergedSha" </del> <ins> # This checks for mergeability of a pull request as recommended in # https://docs.github.com/en/rest/guides/using-the-rest-api-to-interact-with-your-git-database?apiVersion=2022-11-28#checking-mergeability-of-pull-requests while true; do echo "Checking whether the pull request can be merged" prInfo=$(gh api  -H "Accept: application/vnd.github+json"  -H "X-GitHub-Api-Version: 2022-11-28"  /repos/"$GITHUB_REPOSITORY"/pulls/${{ github.event.pull_request.number }}) mergeable=$(jq -r .mergeable <<< "$prInfo") mergedSha=$(jq -r .merge_commit_sha <<< "$prInfo") if [[ "$mergeable" == "null" ]]; then # null indicates that GitHub is still computing whether it's mergeable # Wait a couple seconds before trying again echo "GitHub is still computing whether this PR can be merged, waiting 5 seconds before trying again" sleep 5 else break fi done if [[ "$mergeable" == "true" ]]; then echo "The PR can be merged, checking the merge commit $mergedSha" </ins> else <del> echo "The PR may have a merge conflict" echo "'git ls-remote' output was:" echo "$result" </del> <ins> echo "The PR cannot be merged, it has a merge conflict" </ins> exit 1 fi echo "mergedSha=$mergedSha" >> "$GITHUB_ENV"

Discussion:
Originally posted by in
is the failed workflow run. It looks the same as , but there the problem seems to have been that the PR was merged before the workflow was able to run. This doesn't appear to be the case here though, because the workflow failed at exactly 2023-09-18 14:12:57 but the PR was only merged days later. However, the PR was opened at exactly 2023-09-18 14:12:45, just 12 seconds before the workflow failed. I think the problem can occur when the PR has a merge conflict, or GitHub hasn't computed the merge commit yet, so the ref isn't valid yet. Relevant GitHub docs are : Kind of makes sense, can't get a merge ref before that. I think the best way around this would be to fetch both the latest base branch commit and the PR's head commit, then do an explicit (and skip the worflow if there's a conflict).
Another case here: , and indeed it's due to a merge conflict, the PR () even got the merge conflict label assigned. Turns out the manual merging idea is pretty tricky, because to merge two commits, git needs a common ancestor, but Git doesn't have that without fetching the Git history, and GitHub doesn't have an API endpoint for getting that either. Maybe the best approach here is to have a step before the checkout which just resolves the merge ref using And fails with a better error if it can't be resolved. (If it can be resolved, that resolved SHA should get used in following steps to avoid a potential race condition).
I just created which improves the error message in case of conflicts. I'll consider this fixed after that.
Looks like it's not just merge conflicts that can cause this: The corresponding PR definitely doesn't have a merge conflict: opened to hopefully see what's going on in the future. I'll open this issue again for now
I think this is the solution: See also
This should be fixed by