Why use PR last head and not merge commit for checks

According to the documentation of the pull request API, the status of the checks is the one from the head branch.

statuses The API location of this Pull Request’s commit statuses, which are the statuses of its head branch.

Why isn’t it using the status of the merge commit (pointed to by refs/pull/:PRid:/merge) ?

I think it is wrong to assign checks done a pull request (using merge commits) on the last head commit:

  • It is not the real commit that is tested
  • It will yield different results based on the destination branch (and the current commit it points to)
  • It will (and already does) cause bugs

Welcome to the GitHub Support Community, @Lectem! :wave:

That’s a great question, one in which I don’t have a good answer for. Neither our documentation nor our GitHub Engineering blog offer an explanation for why it was designed that way.

Taking a step back from the question, I see where you’re coming from in relation to using statuses as a way of indicating the state of a particular change. While that particular link relation for statuses in pull requests will continue to exist in its current form, it’s worth pointing out that status checks are based on external processes. They are designed primarily for our integrators who build applications on top of the GitHub API. The GitHub API provides a status API and a Checks API for these integrators and they’re welcome to choose whichever interface works best for their service.

In other words, GitHub provides the interface and integrators use that interface to inject the data from their service. Given that context, I suggest getting in touch with the person or team that developed the integration that you’re using in your repository and asking them why/how they choose to create commit statuses or check runs for the associated commits in a pull request. In that conversation, you could bring up this difference with them (testing the HEAD of the compare branch versus the merge ref) and see how they would approach this for their application.

Does this help?

In other words, GitHub provides the interface and integrators use that interface to inject the data from their service. Given that context, I suggest getting in touch with the person or team that developed the integration that you’re using in your repository and asking them why/how they choose to create commit statuses or check runs for the associated commits in a pull request.

I am actually building such an integration myself, and the issue is as I said, I can not set the status on the merge request. Well in fact, I can do it, but it doesn’t change the PR status.
I think this is a big issue, is there a way to resolve it somehow ?

:wave: @Lectem: thanks for sharing that extra context. While it is possible to create a commit status or a check run for the merge commit, that commit status or check run won’t have any bearing towards the “mergeability” of the pull request.

As a next step, the best way to share feedback with our product team about the current implementation is by submitting a new request through our official product feedback form. That’s where our product team tracks requests like these in consideration for future iterations of GitHub features.

As a next step, the best way to share feedback with our product team about the current implementation is by submitting a new request through our official product feedback form .

It seems I was not logged in when I sent the feedback a few weeks ago, so it doesn’t appear in my list of tickets. Should I re-open it? I didn’t get any answer.

You’re welcome to submit it again––any feedback sent through that form will be read and evaluated by our product team, but they may not be able to respond to every submission.

I submitted it again a month ago, no answer.
Guess this won’t get a fix :frowning: