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_agentsmethod and see what's the best place for its implementation to live. - This method was used by
Ci::GenerateKubeconfigServicewhich in turn is used byGitlab::Ci::Variables::Builder#kubernetes_variables. So it makes sense forauthorized_cluster_agentsto be used directly inside thekubernetes_variablessomehow, instead of being defined in the wrong place:Ci::Pipeline. - Defining
authorized_cluster_agentsdirectly insideCi::GenerateKubeconfigServicewould causeauthorized_cluster_agentsto be recalculated for each job when building the variables. A better way would be to memoize the content ofauthorized_clustert_agentsin the variables builder since the data depends only onProjectand can be done once for the whole pipeline. This is why the agents are injected in the Kubeconfig generation. - Finally I renamed
Ci::GenerateKubeconfigServicetoGitlab::Kubernetes::Kubeconfig::Generatorfor 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