Remove meta-programming from merge strategy class choice
Problem
grouppipeline execution often has to interact with the auto-merge logic when it comes to supporting the merge train feature.
Since we don't own auto-merge logic we are less familiar with it.
It becomes difficult to track the flow of the auto-merge logic because it uses meta-programming to determine the class used and therefore we can't grep for where AutoMerge:::MergeWhenChecksPassService the class is called.
Example:
def get_service_class(strategy)
return unless all_strategies_ordered_by_preference.include?(strategy)
"::AutoMerge::#{strategy.camelize}Service".constantize
end
We handle this with a comment now but that is less than ideal as strategies are added. Only 1 strategy has the comment.
Fix
Refactor get_service_class to use a map rather than constantizing the strategy name:
def get_service_class(strategy)
return unless all_strategies_ordered_by_preference.include?(strategy)
strategy_to_class_map[strategy]
end
def strategy_to_class_map
{
STRATEGY_MERGE_WHEN_PIPELINE_SUCCEEDS => AutoMerge::MergeWhenPipelineSucceedsService,
STRATEGY_MERGE_WHEN_CHECKS_PASS => AutoMerge::MergeWhenChecksPassService
}
end
This will also allow us to:
- Search for where the
AutoMergeclasses are instantiated - Change the name of the class without changing the strategy names and we are currently violating the bounded context rules with our class name. We need to move the merge train auto merge strategies to the
MergeTrainsBounded Context.
Edited by Allison Browne (PTO 12/19-1/2)