Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • heptapod heptapod
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 161
    • Issues 161
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 0
    • Merge requests 0
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • heptapod
  • heptapodheptapod
  • Merge requests
  • !81

Merged
Created Jun 08, 2020 by Georges Racinet@gracinet🦑Owner

Mercurial specific post receive

  • Overview 0
  • Commits 4
  • Changes 6

(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 MergeRequest::RefreshService).

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 RefreshService:

  • 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).

Closes: #207 (closed), #278 (closed), #268 (closed)

Edited Jun 09, 2020 by Georges Racinet
Assignee
Assign to
Reviewer
Request review from
Time tracking
Source branch: topic/heptapod-stable/hg-post-receive