RFR: 1663: Mark integrated Pull Requests as properly merged in their repositories [v37]
jwaters at openjdk.org
Mon Nov 21 15:45:49 UTC 2022
On Mon, 21 Nov 2022 13:56: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.
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> GitLab should mirror the GitHub status getter
I'm fairly certain the primary concern is that switching to merge integrated PRs into their dependency branches is highly disruptive and creates problems throughout Skara's codebase (this PR no longer does that as of now), and the secondary concern is that which branch the PR was integrated into will end up being lost when implemented this way. I'm still trying to conduct tests on my end, so it will take me a while to get back to you on the comparison on pros and cons of this change however
More information about the skara-dev