chore: ignore merge commits to target branch at tip of history

[halms]

Context: Slack

The pull_request target creates a (fake) merge commit that fails the branch linearity check.

This change tries to detect if the commit at the tip is a merge commit against the target branch.
If that is the case, then it ignores it.

Tried it a bit locally and appears to work, but no guarantees for it 😅

+ a small change to make it nicer to use as a direct shell script

[yannrouillard]

I understand that if the last commit is a merge commit and has the head of the target branch as the left child, you will ignore it (consider it's the GitHub generated one) and check for merge commit in the below commits.

It's not clear to me if this approach works if someone did the same thing in his/her branch that GitHub CI does, i.e. he/she merged the main branch into its development branch, which we also wouldn't want in case of linearity check.

I tried locally and the check worked, but it was because the origin/main commit was the right child of the merge commit and not the left child.

Are you sure testing always the left child will achieve the expected results?
Unfortunately, I was not able to test it in a real PR, I had some difficulties reproducing the issue.

BTW I thought initially to use something more GitHub specific, using for instance the environment variable exported.
The GITHUB_SHA contains the tip commit (which will be the merge commit if one was created)
and GITHUB_HEAD_REF contains the source branch name (and is only defined in PR context)

If the 2 don't point to the same thing, we are probably in a GitHub merge commit situation.
Or simpler, if GITHUB_HEAD_REF is non-empty, we do git rev-parse ${GITHUB_HEAD_REF} to get the tip commit to use.

BTW I found this page informative about the process: https://www.kenmuse.com/blog/the-many-shas-of-a-github-pull-request/

[yannrouillard]

Ok I think it will work because locally the left child is the target of the merge (ours) and the right side what is merged into the target (theirs).
A local merge commit will merge main into the current branch, so it will end up on the right.
Whereas GitHub create a new branch from the base commit and merge the pull request branch into it so the origin/main commit will be on the left.

I still think using GITHUB_HEAD_REF would be simpler but as you want :-)

[halms]

Took me a while (and needed some calm time) to wholly follow through your points.
I have to say, I did not think at all about any GH-specific variables, only about the git history itself. But what you suggested makes a lot of sense.

So the case you were concerned about is if we have a merge commit from main into the dev branch (what we don't want to allow) at the tip of the history.
But this is detected correctly because it has the left and right parent commits inversed.

In any case, yes, I think using the GITHUB_HEAD_REF is a good idea here. And ignoring it if it's empty.
We could even compare SHAs of rev-parse $GITHUB_HEAD_REF and HEAD^ and if they match assume we are in a GH merge commit scenario and start the history check from that SHA?

[yannrouillard]

I think we can simplify the check for GitHub case and be more sure it works in all cases.
See my comment.

[halms]

I recently stumbled across this and picked it up again, building on top of GITHUB_HEAD_REF.
Took a bit of trial and error to have both happy case and case to capture work both locally and on GH (in PR context).

Aimed to not have to fetch full git history, but only the shallow parts that are needed.

Tested runs in a temp branch in another repo: happy case, merge caught.