allow_k8s_contexts not properly enforced when changing context with kubectl about tilt HOT 5 OPEN

hmmmmm....i was not able to reproduce the behavior you're describing. But I think there's a bit of confusion about the expected behavior. Here's what I tried:

• Created two kind clusters
• Ran kubectl config use-context kind-a
• Checked out the example project at https://github.com/tilt-dev/tilt-example-html/tree/master/0-base
• Ran tilt up
• Ran kubectl config use-context kind-b
• Made a change to the image
• Verified that the image was deployed to kind-a

The behavior I would expect is that Tilt reads the kubeconfig at startup, and continues to deploy to the same cluster, even if your current context changes.

Do you have additional repro steps?

from tilt.

Unfortunately after playing around a bunch I also can't reproduce the bug.
To fill in some additional defails.

1. Starting tilt with the remote cluster as context yields the expected error due to beeing potentially on production.
   -> I could not have started tilt by accident on the affected cluster as it would not have applied anything. I am certain the allowed context is and was docker-desktop as I did not change that at all. Also docker-desktop is the local cluster and not some sadistic rename.
2. This happened after my laptop was suspended for around 14 hours.
3. Parts of tilt were likely building a container and a local helm chart was likely reinstalled, because the affected file was not in the .helmignore or .dockerignore

To me this feels like a very weird race condition. I am not familiar with the codebase, but do you know how tilt handles the context internally? Are kubectl commands always applied with a pinned context?
At some point tilt must have switched the context even skipping the k8s_context validation.

from tilt.

Is tilt maybe working with tokens to authenticate to the api and because >14h passed, it expired and it had to renew it bypassing the checks and using the current-context?

from tilt.

tilt reads the kubeconfig at startup, minifies it (removing all the other kube contexts), writes a new minified kubeconfig to a different place on disk, and uses that one for all future connection settings. If you run tilt get cluster -o yaml, you can see what it's using.

from tilt.

The config it writes to:
tilt get cluster -ojsonpath='{.items[*].status.connection.kubernetes.configPath}'
is not used by tilt itself? When deleting it tilt still works.
There is a config at ~/.tilt-dev though and even deleting that does not prevent tilt from talking to the cluster. There has to be some in memory state.
Shooting in the dark here, but the long time between the tilt updates and communication with the apiserver is probably key to this. Maybe there is some broken error handling when reestablishing a connection?

from tilt.