Add CI Variables builder, prometheus timing
What does this MR do and why?
This moves the CI Variables scoped_variables
generation out of models in an iterative fashion and into a Gitlab::Ci::Variables::Builder
class.
This class is the single entry-point for creating Ci Variables, and takes a pipeline
argument to initialize it.
Scoped variables can be accessed by calling Gitlab::Ci::Variables::Builder.new(pipeline).scoped_variables(build, environment:, dependencies:)
. We are using this in Contextable#scoped_variables
(for Build / Bridge).
It uses dependency injection in order to generate variables for specific object - i.e for a Build
you can call Gitlab::Ci::Variables::Builder.new(pipeline).scoped_variables(build)
.
Feature Flag
To ensure safety we put #scoped_variables
behind a feature flag, ci_predefined_vars_in_builder
.
We currently are only using generating the pipeline predefined_variables
using the builder.
To measure performance of the #scoped_variable
method, we add tracking to app/models/concerns/ci/contextable.rb
which measures the duration (under gitlab_ci_pipeline_builder_scoped_variables_duration
).
As we move more methods into the Variable builder version of #scoped_variable
, and add memoization, we should see the duration decline.
Related: #231300 (closed) Previous MR, before broken up: !71439 (closed)
Screenshots or screen recordings
These are strongly recommended to assist reviewers and reduce the time to merge your change.
How to set up and validate locally
Numbered steps to set up and validate the change are strongly suggested.
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.