Feature for kubecontext section: Custom colors per context/namespace

[nomaed]

Description

This change adds a new feature for the kubecontext section.
It allows setting SPACESHIP_KUBECONTEXT_COLORGROUPS array with colors and patterns that match context names and namespaces, that should change the section to the specified color. This is usually going to be critical environments that we need to make sure we don't modify by mistake, such as "production" or "staging" (as opposed to regular "dev").

This is an idea by a colleague after too many people not noticing that they are on the production environment and deploying changes, when all they wanted is to test changes in local development env.

Screenshot

[maximbaz]

This is interesting idea, I'd totally use it myself.

Here's what I'd like to be added:

1. Support more than one group with different colors (most common groups would be "staging" and "production", but for example we also have an extra cluster for testers and an extra cluster for various early experiments — in my case I would like to avoid experimenting on "dev" cluster).
2. Support regex rule for defining groups, speaking only of production clusters we have 8 of them and I would be annoyed to list them all. But they all follow a naming scheme, so I'd really like to define rules as *-prod-* for production, *-dev-* for development, etc.

I'm wondering how to make the first point generic enough, I don't think hardcoding "popular" groups is good enough. Ideally we allow people to configure as many "rulepattern-color" pairs as they want.

[maximbaz]

Just realized that the second point will actually work out of the box, if you don't wrap your name in quotes.

So we only need to change how we define pattern-color pairs, to make it more generic.

[nomaed]

Regex

I love the idea of regex, that will definitely make life easier.
However, not sure that your example will work since you can't define such patterns in a list AFAIK:

$ arr=(*-dev-*)
zsh: no matches found: *-dev-*

It can work with actual regex with =~ comparator, although this means that any regex-special character in the name will need to be escaped and it will be less user friendly.

ctx=(".*-dev-.*" ".*-prod$" exact-context)
...
if [[ $kube_context =~ $crit ]]; then ...

Do you think it's good enough to specify that the list of context names is a list of regular expressions rather than strings or expandable patterns? Or is there another way to achieve adding these patterns to a list, to use the syntax you suggested?

Edit:
This doesn't work...

$ setopt GLOB_SUBST; [[ "my-dev-cl" == "*-dev-*" ]] && echo y || echo n; unsetopt GLOB_SUBST
n

Groups

I agree that it's a great idea, but it sounds like a lot of pain for the user to configure.
Initially I thought that an assoc array can make it quite simple, something like bash syntax:

ctx=(
  [red] = (*-prod *-staging)
  [yellow] = (*-dev-*)
)

but discovered very fast that it's not a supported syntax, and that having a multi-dimensional array is not supported either and is much more pain to implement than its worth :)

The next idea is something like:

USE_GROUPS=(prod dev blah)
GROUP_prod_COLOR=red
GROUP_prod_PATTERNS=(".+-prod" ".+-staging")
GROUP_dev_COLOR=yellow
GROUP_dev_PATTERNS=(".+-dev-.+")

or something in that direction. However, the list of group "names" is really not useful, it's just there to be able to build a list of variables to iterate over (and I still haven't figured how to use regex comparison...)

[maximbaz]

Agree on using regex, and using associative arrays is cool too.

How about this approach?

declare -A SPACESHIP_KUBECONTEXT_COLORGROUPS=(
  [-test-]=yellow
  [-prod-]=red
  [-staging-]=red
)

cluster="my-prod-cluster"

for pattern color in ${(kv)SPACESHIP_KUBECONTEXT_COLORGROUPS}; do
  echo "testing $cluster against $pattern"
  if [[ "$cluster" =~ "$pattern" ]]; then
    echo "matches $pattern!!!"
  fi
done

UPDATE: apparently .*-test-.* is the same as -test-, so simplified.

[nomaed]

@maximbaz Your syntax is very usable :)

I went with your suggestion and changed the code to support SPACESHIP_KUBECONTEXT_COLORGROUPS and it works quite well!

typeset -A SPACESHIP_KUBECONTEXT_COLORGROUPS=(
  ['dev-system']=green
  ['production']=red
  ['staging']=red
  ['^test-[0-9]+$']=yellow
  ['\.k8s\.local$']=red
)

[maximbaz]

Now it's very cool 👍 Can you explain why you have == || =~ in code, why not just =~ alone?

[nomaed]

I figured that testing for equality first might have a tiny benefit for performance. If there's exact match, there's really no need to do a regex match.
However, I haven't tested whether it has any actual performance benefit and it might be just a case premature optimization on my side...

Also, the idea that you can set up first dev as exact match and then dev-.+ as a different color. If there is only =~, having "dev" will also match "dev-123" so you'd have to specify it as ^dev$

[maximbaz]

I wouldn't worry about this, use =~ alone and once spaceship is officially async it wouldn't matter at all.

[maximbaz]

Works beautifully, nice addition

[nomaed]

Thanks for the reviews!

[maximbaz]

Friendly ping @salmanulfarzy, this is something very cool and prevents accidentally messing with production environment, definitely worth merging and letting people know that this functionality exists.

[salmanulfarzy]

This looks great @nomaed 👏 Proposing some minor changes.

[nomaed]

I made the changes per review comments:

• Options.md specifies the default value to be empty
• Options.md example: comments in code are one line above to make it cleaner
• Renamed SPACESHIP_KUBECONTEXT_COLORGROUPS to SPACESHIP_KUBECONTEXT_COLOR_GROUPS
• Quotes unassigned local variable definitions

[salmanulfarzy]

Thank you @nomaed, Made some minor changes myself.

[salmanulfarzy]

Code looks great @nomaed

[nomaed]

Super, thank you guys!

[salmanulfarzy]

Thank you for contributing 🎉

@nomaed @maximbaz can you guys share screenshot/gif to be shared on Twitter with default settings ? Do share your twitter handle if you've one 😄