Skip to content

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:

  1. Try to remove Ci::Pipeline#authorized_cluster_agents method and see what's the best place for its implementation to live.
  2. This method was used by Ci::GenerateKubeconfigService which in turn is used by Gitlab::Ci::Variables::Builder#kubernetes_variables. So it makes sense for authorized_cluster_agents to be used directly inside the kubernetes_variables somehow, instead of being defined in the wrong place: Ci::Pipeline.
  3. Defining authorized_cluster_agents directly inside Ci::GenerateKubeconfigService would cause authorized_cluster_agents to be recalculated for each job when building the variables. A better way would be to memoize the content of authorized_clustert_agents in the variables builder since the data depends only on Project and can be done once for the whole pipeline. This is why the agents are injected in the Kubeconfig generation.
  4. Finally I renamed Ci::GenerateKubeconfigService to Gitlab::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.

MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

Edited by Fabio Pitino

Merge request reports