Last big part before splitting pulselistener in lib & client applications. Refs #2185.
This PR changes several important things:
MercurialWorker only applies PhabricatorBuild and their pre-loaded stack of patches: there is no Phabricator API calls there anymore.
A new generic PhabricatorActions class is available in the library: it has the only PhabricatorAPI instance in pulselistener, and exposes it through high level functions. No queue usage here, as it's the responsability of the client application.
PhabricatorBuild does not have any inner logic anymore, it simply stores data.
A PhabricatorPatch tuple is added to store efficiently the stack of patches, which is built only from Phabricator (no repository check when creating the stack)
A PhabricatorCodeReview class extending PhabricatorActions is added in the client application, and contains the workflow specific to code review: building specific mercurial repositories, pre-loading builds with stack of patches & reviewers once they reach the public state.
A new queue is added in the application, to pre-load Phabricator builds with extended data before reaching the mercurial worker.
In the end, the code review workflow through queues is:
Build triggered through the webserver and stored in QUEUE_WEB_BUILDS
QUEUE_WEB_BUILDS is read by PhabricatorCodeReview, once the build is seen as public, it is pre-loaded with Phabricator data, and pused in QUEUE_CODE_REVIEW.
QUEUE_CODE_REVIEW is read by HookPhabricator which just pushes it to QUEUE_MERCURIAL & QUEUE_PHABRICATOR_RESULTS (+ risk analysis workflow)
Last big part before splitting pulselistener in lib & client applications. Refs #2185.
This PR changes several important things:
MercurialWorkeronly appliesPhabricatorBuildand their pre-loaded stack of patches: there is no Phabricator API calls there anymore.PhabricatorActionsclass is available in the library: it has the onlyPhabricatorAPIinstance in pulselistener, and exposes it through high level functions. No queue usage here, as it's the responsability of the client application.PhabricatorBuilddoes not have any inner logic anymore, it simply stores data.PhabricatorPatchtuple is added to store efficiently the stack of patches, which is built only from Phabricator (no repository check when creating the stack)PhabricatorCodeReviewclass extendingPhabricatorActionsis added in the client application, and contains the workflow specific to code review: building specific mercurial repositories, pre-loading builds with stack of patches & reviewers once they reach the public state.In the end, the code review workflow through queues is:
QUEUE_WEB_BUILDSQUEUE_WEB_BUILDSis read byPhabricatorCodeReview, once the build is seen as public, it is pre-loaded with Phabricator data, and pused inQUEUE_CODE_REVIEW.QUEUE_CODE_REVIEWis read byHookPhabricatorwhich just pushes it toQUEUE_MERCURIAL&QUEUE_PHABRICATOR_RESULTS(+ risk analysis workflow)