What happened?
I'm using some devspace command to spin up a kind cluster. The kubeconfig is located in the projects root, e.g. ./dev/run/kubeconfig not to interfere with any exising real clusters.

I was using the var DEVSPACE_FLAGS to set the kubeconfig and the kube-context arguments.
When running a pipeline it cannot access the kubeconfig thworing this error

warn Unable to create new kubectl client: kube config is invalid

create_deployments: Please make sure you have an existing valid kube config. You might want to check one of the following things:

* Make sure you can use 'kubectl get namespaces' locally
* If you are using Loft, you might want to run 'devspace create space' or 'loft create space'

fatal exit status 1

I can do some really ugly workarounds i really don't like, e.g.:

1. writing a wrapper script around devspace that sets the arguments explicitly
2. devspace run-pipeline init --kubeconfig dev/run/kubeconfig
3. KUBECONFIG=./dev/run/kubeconfig devspace run-pipeline init

I liked the idea of keeping things clear and well defined and explicit in yaml files.
So this seems like a bug to me.

What did you expect to happen instead?

I expected that i can pass the kubeconfig i like without

How can we reproduce the bug? (as minimally and precisely as possible)

My devspace.yaml:

version: v2beta1
name: foo
vars:
  DEVSPACE_FLAGS: -s --kubeconfig ./dev/run/kubeconfig --kube-context kind-mycluster

Local Environment:

• DevSpace Version: DevSpace version : 6.3.12
• Operating System:linux
• ARCH of the OS: AMD64
  Kubernetes Cluster:
• Cloud Provider: kind

Anything else we need to know?

At a first glance the problem seems that the KUBECONFIG variable is not evaluated after the root command is executed:

Setting the --kubeconfig argument via the DEVSPACE_FLAGS variable should trigger setting the KUBECONFIG env variable as well.