Closed rudyflores closed 1 year ago
LGTM! 😋 Thank you for considering adding these. Should we prefix them with
ZOWE_K8S_
?
The reason for choosing these names is because it seems like when logging into a Kubernetes cluster, it is common practice to have these variables named this way. I could have the plugin look for a third variable this being ZOWE_K8S
but the two variables provided in the readme of this PR should be sufficient since these are the normal variable names assigned to that env when logging into Kubernetes.
LGTM! 😋 Thank you for considering adding these. Should we prefix them with
ZOWE_K8S_
?The reason for choosing these names is because it seems like when logging into a Kubernetes cluster, it is common practice to have these variables named this way. I could have the plugin look for a third variable this being
ZOWE_K8S
but the two variables provided in the readme of this PR should be sufficient since these are the normal variable names assigned to that env when logging into Kubernetes.
Thanks for clarifying. No need for a 3rd variable 😋 one more (likely dumb) question:
DEVWORK....
before WORK....
)I guess I was thinking that a developer may want their environment variable to take precedence over the regular version of the env variable? 😋
Potentially resolves #9
This PR adds a simple change to the way we originally handled loading the initial workspace where the secrets are stored in the credential manager plugin. With this change, if an environment variable of
$WORKSPACE_NAMESPACE
or$DEVWORKSPACE_NAMESPACE
is present, then the credential plugin will set the default namespace to be of that environment variable.