Profiles activation based on devspace variables

[tbondarchuk]

Would be nice to be able to activate profile based on devspace's variables like DEVSPACE_NAMESPACE. Those are accessible in vars source command, but not as env var for activation.

P.S. Profiles activation has been merged 5 days ago and here I am asking for even more features:) I'm just loving all the devspace's flexibility, thought it would be nice to expand it even more. Hope I don't seem as too demanding.

/kind feature

[FabianKramm]

@aliusmiles thanks for creating this issue! Currently the problem with profile activation from variables is that you can use profiles to change variable default values for example, so the order wouldn't be clear anymore when profiles and when variables are loaded, so this is a rather tricky request. But I can definitely see that this would be very useful.

[tbondarchuk]

I've just tested and it doesn't seem to be possible to overwrite DEVSPACE_NAMESPACE with vars, top-level or in profile. I suppose all Predefined Variables are not editable so it should't cause recursion?

I was looking for something like skaffold's profile activation based on kube context, but option to use context, namespace and possibly git branch as activation trigger would be really nice.

My personal usecase is a bit weird: app is deployed in dev and dev-username1, dev-username2 namespaces with shared helm values (dev-username is using dev's values file) but with some values like ingress being env/ns specific (like app-dev-username1.local) But I believe context/namespace based activation could be used in much more cases, like using different profiles for local/dev/prod clusters, etc.

[FabianKramm]

@aliusmiles thats correct, predefined variables cannot be overriden and would work, however all other variables wouldn't. We can maybe implement something that the variables that are used for activation are resolved beforehand and cannot be changed afterwards to allow them for activation

[tbondarchuk]

Trying to think about usecase for profile activation based on custom var defined in top level vars: source env doesn't make sense as we can can already activate directly from env var, source value is static so kind of no point, so maybe source input with/without options? Something like: run devspace, get prompted for variable value, continue with profile based on value. But that's still requires manual actions, I can just type -p profile instead I guess. Though it does looks a bit more convenient.

But using context/namespace for activation will completely eliminate manual actions. Plus I suspect that activation on predefined vars is way easier to implement then based on any var :)

[FabianKramm]

@aliusmiles that is true, however one use case which would be very useful as well would be variables from commands, where you essentially could define your custom logic when a profile would be activated. So I guess predefined variables and variables that are filled by scripts / commands are the most useful one in this scenario