Extract Ci::EnqueueJobService
Problem
In !56492 (comment 529230865) we highlighted the need to add a generalized way to enqueue jobs. We seem to do it slightly differently in
Ci::PlayBuildService
Ci::PlayBridgeService
-
--> Follow-upCi::RetryJobService
-
Ci::Pipeline#reset_source_bridge!
(!60376 (merged)) (Optional: !60376 (comment 564911366))
and this could cause problems if the logic differs.
When a job is enqueued we always need to:
- assign the current user to it
- pass in any variables
- enqueue the job consistently (should we always use optimistic locking)?
- call
Ci::AfterRequeueJobService
to run the side-effects if enqueue is successful
Solution
Extract a Ci::EnqueueJobService
that does the above and will be reused in
Ci::PlayBuildService
Ci::PlayBridgeService
-
--> Follow-upCi::RetryJobService
-
Ci::Pipeline#reset_source_bridge!
(!60376 (merged)) (Optional: !60376 (comment 564911366))
Follow-up
(2022-11-21) The code for Ci::RetryJobService
recently updated such that Gitlab::OptimisticLocking.retry_lock(job, name: 'retry_build', &enqueue)
no longer runs. This operation was replaced with Ci::PipelineCreation::StartPipelineService.new(job.pipeline).execute
. Determined that it does not require a refactor at this time. See follow-up.
Implementation
backend | MR |
---|---|
Extracts Ci::EnqueueJobService and reuses it in Ci::PlayBuildService , Ci::PlayBridgeService , and Ci::Pipeline#reset_source_bridge!
|
!104454 (merged) |
Edited by Leaminn Ma