Mercurial specific post-receive
For %Heptapod 0.12.0, we've managed to fix the merge detection without changes to the notifications that Mercurial sends to GitLab upon reception of new changesets: it is still a standard Git "post-receive" payload.
This led us in particular to stop notifying Git branch deletions for published topics, letting GitLab itself remove the branch after all relevant Merge Requests have been examined. This was necessary because merge detection had become much more asynchronous in GitLab 12 than it was in GitLab 10.5.
But this strategy has its limits:
- bad performance. Not so much visible to users, since everything happens asynchronously, but undue stress of the workers is bad for the whole application.
- it relies on an edge case of the post-receive format: we're actually including pseudo changes with
oldrev==newrev
to trigger detection from the source branch. Then we have to exclude these from pipelines - #268 (closed): if the topic moves and gets published in a single push, the pipeline exclusion mentioned above does not apply.
- it won't make sense when we go Mercurial native thanks to the HGitaly project.
- we have no way to take the case of (named) branches closed before they are merged into account. This is #207 (closed).
- users get MR creation prompts for the very topics they are publishing (no specific issue for this).
It would make much more sense to introduce a new internal API point tailored for Mercurial changes, which could carry over more information, notably explicit phase changes and closing information.
Not only would our merge detection stop being slower than normal in GitLab, but it would become faster, at least for topics: no need to call the VCS back for ancestry assessment when all the information is already available.
Would be neat for 0.13.0, but that would be done after rc1