Merge Kubeconfigs when both integration methods are available for a cluster/project
Proposed release notes
Starting with GitLab 14.9, GitLab agent based connections are also available when deploying to environments that already have a certificate-based cluster. Previously, migrating from a certificate-based connection to an agent-based setup required extra steps and was especially difficult for group and instance-level clusters. By presetting both Kubernetes contexts, migration is largely simplified to selecting the context provided by the agent, instead of the default context, provided by the certificate-based connection.
Problem to solve
When a project has both a certificate-based cluster and an agent CI/CD tunnel shared with it, the
KUBECONFIG only includes the certificate-based cluster's context. This makes it impossible to migrate projects under group-level clusters and instance-level clusters one-by-one to an agnent-based CI/CD workflow.
Provide a merged
KUBECONFIG that includes both the old certificate-based cluster and the agent contexts.
Originally raised by @marshall007:
Also note that the legacy cluster integration appears to indiscriminately set the
KUBECONFIGCI variable without checking to see if it has already been defined or attempting to merge them. I think it is important that you get a merged
KUBECONFIGwhen both integrations are enabled so we can more easily migrate projects away from the legacy cluster integration.