Draft: Remove cluster agents from Ci::Pipeline
What does this MR do and why?
In this MR I wanted to remove Ci::Pipeline#authorized_cluster_agents
away from Ci::Pipeline
model since it's not behavior that belongs to a pipeline. The Pipeline
object was simply used because it has a reference to Project
.
To solve this design smell I took the following steps:
- Try to remove
Ci::Pipeline#authorized_cluster_agents
method and see what's the best place for its implementation to live. - This method was used by
Ci::GenerateKubeconfigService
which in turn is used byGitlab::Ci::Variables::Builder#kubernetes_variables
. So it makes sense forauthorized_cluster_agents
to be used directly inside thekubernetes_variables
somehow, instead of being defined in the wrong place:Ci::Pipeline
. - Defining
authorized_cluster_agents
directly insideCi::GenerateKubeconfigService
would causeauthorized_cluster_agents
to be recalculated for each job when building the variables. A better way would be to memoize the content ofauthorized_clustert_agents
in the variables builder since the data depends only onProject
and can be done once for the whole pipeline. This is why the agents are injected in the Kubeconfig generation. - Finally I renamed
Ci::GenerateKubeconfigService
toGitlab::Kubernetes::Kubeconfig::Generator
for 2 reasons:- CI doesn't own Kubernetes Kubeconfig logic. We already have a namespace
Gitlab::Kubernetes::Kubeconfig::
which makes sense to be used here. - The class is not really a service object (no business logic) but more a configuration builder.
- CI doesn't own Kubernetes Kubeconfig logic. We already have a 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.
Edited by Fabio Pitino