Draft: Define `Ci::PipelineDraft` class to represent a pipeline being created
What does this MR do and why?
Related to Create abstraction to manipulate a draft pipeline (#466429)
The Ci::PipelineBuilder::DraftPipeline
represents an in-memory pipeline being built. Rather than using the AR model Ci::Pipeline
everywhere, which we could in theory do too much, we would rely on this object that is an abstraction on top of Ci::Pipeline
.
This MR builds on top of the refactoring Draft: Extract Ci::PipelineBuilder concept to c... (!153895). It's only a scratch refactoring to help me understand how far we can push this design and see if it's worth. If we like this pattern we will then split this MR into small ones.
Advantages:
- It provides only the necessary methods to build a pipeline. Currently there are many more because
Chain::Command
violates the "Tell, Don't Ask" principle and requests a lot of data. We could instead move a lot of the data fromChain::Command
, especially those related to the pipeline data, inside theDraftPipeline
class. - In the context of Pipeline Execution Policy we need to inject jobs into specific stages in an in-memory pipeline, before it's persisted. The
DraftPipeline
object can abstract away all the complexity of adding jobs into specific stages in a pipeline (e.g. deal with stage indexes), making it easier to modify a pipeline using a safer abstraction. - This abstraction enforces invariants in the pipeline data structure. For example the
add_error
method takes care of all the ways we represent errors in a pipeline record. - We have the
Chain::*
classes that deal more with an abstraction rather than with all the implementation details of an AR model. - The
Chain::SeedBlock
could yield aCi::PipelineBuilder::DraftPipeline
object instead of theCi::Pipeline
AR which is too powerful. This will help solving Allow Chain::SeedBlock to run only predefined a... (#462013)
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Screenshots or screen recordings
Screenshots are required for UI changes, and strongly recommended for all other merge requests.
Before | After |
---|---|
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.