Adds support for specifying valid context names for an environment

[Nashluffy]

#58 (comment)

I appreciate the protection spec.apiServer provides, but Tanka does not work for our environments without support for matching on context names. I'm happy to update docs if this is something that would potentially be merged.

Our use case is summed up in the comment at the top.

Example spec.json

{
  "apiVersion": "tanka.dev/v1alpha1",
  "kind": "Environment",
  "metadata": {
    "name": "environments/development"
  },
  "spec": {
    "contextNames": ["automation-generated-context", "local-generated-context"],
    "namespace": "default",
    "resourceDefaults": {},
    "expectVersions": {}
  }
}

There's also a bug this PR fixes with an empty env.Spec.APIServer where the value will never be an empty string in (l LoadResult) Connect() because of the regular expression check in func Parse(data []byte, namespace string) (*v1alpha1.Environment, error). The fix is to only prepend that if the APIServer is not an empty string.

[malcolmholmes]

You don't address "why" you cannot use the apiServer address. Without that, I don't think we can reason about why we should add this feature, which, to our minds would be a regression. Can you explain your need?

[Nashluffy]

You don't address "why" you cannot use the apiServer address. Without that, I don't think we can reason about why we should add this feature, which, to our minds would be a regression. Can you explain your need?

Sure, I've outlined our use-case in this issue #686. Let me know if more details are needed. Thanks!

[sh0rez]

hi! thanks for the pr :D

I'm generally happy to go forward with this, but I can't follow why you would want to specify multiple contexts in the spec.json.
unless I miss something, kubectl operates on a single context only, and so should tanka (it currently does).

so what's the use-case for having multiple here?

[Nashluffy]

There are two ways of pulling a kubeconfig for our clusters: from our cloud provider CLI, or from Teleport. Both use different naming conventions for the context and we have no control over that. The network our Jenkins instance is on cannot reach the network our Teleport instance is on, meaning users pull configs locally via Teleport and Jenkins pulls configs via our cloud provider CLI. Also, the way Jenkins pulls configs is currently our break-glass solution if Teleport is ever down. Supporting both naming conventions means we don't need to change the spec.json depending on where we are running tk from.

The PR actually has two ways to handle this case, using "example-cluster" for the cluster name

Explicitly listing each context name

  "spec": {
    "contextNames": ["automation-example-cluster", "local-example-cluster"],

Using a regular expression

  "spec": {
    "contextNames": [".*example-cluster.*"],

I can restrict the PR to only support one of the two, if that's more desirable.

[Nashluffy]

Hi all - let me know if the above explanation justifies the field's support. I also added a reference to this field in the docs as it's currently implemented.

[julienduchesne]

LGTM!

[julienduchesne]

@sh0rez What do you think?