RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v57]

[Erik Joelsson]

On Tue, 3 Jan 2023 06:07:50 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Skara currently closes integrated Pull Requests, since the actual integration is done internally and then pushed to the repository separately. This makes every integrated request always look like it was closed to an outside observer, forcing the use of a special integrated flag to distinguish between integrated and closed, or rejected and closed. On top of that, it just looks awful in the interface all around (and is also not included in the accepted Pull Request count by GitHub for the committer, which is frustrating for newer contributors to a surprising extent). In the [willful absence of a reply from the GitHub team to allow marking a pull request as merged through a flag](https://github.com/orgs/community/discussions/12437), and [GitLab being unlikely to make a similar change either](https://gitlab.com/gitlab-org/gitlab/-/issues/16701), we can look at implementing this as an integration feature in Skara itself instead.
>> 
>> Every pull has a corresponding pre-integration branch created at the time it was made, and this special branch is marked for deletion when the pull is integrated, and initially it was thought to merge the Pull Request into these corresponding pr/ branches just before their deletion but that proved to present too many challenges to be viable. Instead a related approach of enhancing the Pull Request bots with their own special integration branches can be taken, as well as providing a flexible utility method for extracting the actual branch the Pull Request was integrated into, to address the concern of losing information on what the actual Pull Request target branch was.
>> 
>> 
>> https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/models/merge_request.rb#L172
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ensure fetch properly advances local branch

> Is there any reason why Skara doesn't use (or emulate in a way that is detected if there's no direct way/endpoint) what GitHub does when using the "Rebase and Merge" button?
> 
> That marks pull requests as merged unless it's changed recently, without making the rebase directly in the PR branch.
> Sorry I've said it wrong, I was referring to Squash and merge this entire time, for some reason confused it with rebase.

An important design choice in Skara was to make sure it was compatible with at least 2 different hosting providers (currently github and gitlab) so that we did not build in a hard dependency on a single provider. This means we can't lean too heavily on functionality specific to any one provider, but rather prefer to implement general solutions that can be used with both/all. 

I can't say if there is anything in particular that the GitHub API of today is missing that would hinder us from using it for squash merging PRs, at least not without spending a considerable amount of time investigating. I'm pretty sure the original implementors of Skara found that the current strategy was necessary to support the OpenJDK process on both GitLab and GitHub at the time it was implemented, and I trust their judgement.

-------------

PR: https://git.openjdk.org/skara/pull/1409