Mercurial specific post receive
(relies on matching changes in py-heptapod)
This introduces a new, optional,
hg_prunes field in the GitLab post-receive internal API call, and uses it for early Merge Request detection.
This new MR detection is asynchronous, like most of the post-receive treatment, but it happens before further workers are spawned for the standard treatment of branch updates (including GitLab's standard MR detection, done by
The underlying assumption is that with extra information, it is cheaper anyway to perform the detection in the most common cases, so that we don't need to split in subworkers (would create the complicated issue to trigger the
BranchUpdateWorkers only after they are all complete or to forward the
hg_prune information all the way to them).
This has several advantages over the double detection Heptapod previously had in
- simpler, less redundant and potentially racy, should be much cheaper
- ready for unconditional GitLab branch vanishing before the post-receive is sent (what will happen with Heptapod 0.14 anyway). We previously were using hacky conventions in the payload and pruning from GitLab, with consequences such as #268 (closed) (phantom pipelines) or #278 (closed) (topics that should have been pruned).
- can handle cases that were too complicated to represent even with hacky conventions, such as #207 (closed) (closed branches).