Draft: Define `Ci::PipelineDraft` class to represent a pipeline being created

Fabio Pitinorequested to merge
fp-pipeline-draft-class into extract-pipeline-builder-step

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 from Chain::Command, especially those related to the pipeline data, inside the DraftPipeline 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 a Ci::PipelineBuilder::DraftPipeline object instead of the Ci::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.

Edited by Fabio Pitino

Merge request reports