Move CI config loading to dedicated module
Context
Historically, CI config files have been loaded using Gitlab::Ci::Config::Yaml.load!
. However, we recently introduced CI headers and CI inputs, which are loaded by combining Gitlab::Ci::Config::Yaml.load_result!
with External::Interpolator
. The logic that manages the returns from load_result!
and Interpolator
lives in External::File::Base
, so it can only be used to interpolate configurations loaded through the include
keyword.
The refactor being tracked in #409846 (closed) aims to complete 2 objectives:
- Make it possible to parse CI headers and interpolate inputs in every location where we load CI configuration files
- Make it easy to load CI configurations by creating a single source of truth that handles both loading YAML and interpolating the loaded YAML
What does this MR do and why?
This MR is the first MR for #409846 (closed), which aims to create a single source for loading CI configuration YAML files.
- It moves the CI config loading logic into a dedicated
Gitlab::Ci::Config::Yaml::Loader
class. In the next MR we'll be refactoring this class to make it easier to check whether the loaded YAML is valid, read errors from the loading process, and add logging - It also moves the CI config input interpolator from the
External
module to theYaml
module - since we'll be interpolating inputs anywhere we load CI configs, it makes sense to putInterpolator
in a more generic namespace
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #409846 (closed)