Question: Is there a way to skip the kubernetes context check?

[dexhorthy]

Right now I have the following Tiltfile, which consists entirely of local_resource declarations to run go tests for certain packages

# Tiltfile
local_resource('go tests', cmd='go test -v ./pkg/...', deps=['./pkg/'])

But when I tilt up, it notices I am using a GKE kube context and (rightly) prevents startup:

       gke_smart-proxy-839_us-central1-b_dex-kots-tester might be a production     
       kube context.                                                               
       If you're sure you want to continue add:                                    
       allow_k8s_contexts('gke_smart-proxy-839_us-central1-b_dex-kots-tester')     
       before this function call in your Tiltfile. Otherwise, switch k8s           
       contexts and restart Tilt.  

And while I can certainly do this, I'm wondering if there's a way to automatically skip the context check if all Tiltfile invocations are local_resource and there is no k8s_yaml or docker_build.

(note -- I'm not at all blocked on this, I can certainly switch my context to docker-for-desktop temporarily while using this Tiltfile)

Tilt: v0.12.7, built 2020-03-09
System: darwin-amd64
---
Docker
- Host: [default]
- Version: 1.40
- Builder: 2
---
Kubernetes
- Env: gke
- Context: gke_smart-proxy-839_us-central1-b_dex-kots-tester
- Cluster Name: gke_smart-proxy-839_us-central1-b_dex-kots-tester
- Namespace: default
- Container Runtime: docker
- Version: v1.14.10-gke.17
---
Thanks for seeing the Tilt Doctor!
Please send the info above when filing bug reports. 💗

The info below helps us understand how you're using Tilt so we can improve,
but is not required to ask for help.
---
Analytics Settings
- User Mode: opt-in
- Machine: 503519e6fa9251f8c1b296d57e80c78c
- Repo: j+D3yI+Wl4UG3HEcwDSrdw==

[maiamcc]

Huh, good catch, that's not great 😅

From a quick look at the code, we SHOULD only be checking the context in two cases:

1. if there are any k8s resources, or
2. if there are calls to local -- because we can't guarantee that the user isn't calling out to kubectl

Seems like (1) is not the case for you--but I assume (2) is, i.e. you have some local calls in your Tiltfile? (I'm not saying that this is necessarily what we should do, I'm just double checking that the code is working how I expect it to.)

[nicks]

One thing we've seen people do is:

allow_k8s_contexts(k8s_context())

as in https://github.com/windmilleng/tilt/issues/2357

Some users have expressed the desire to have local/local_resource calls that deploy kubernetes objects (think helm), and to have Tilt make sure they're not accidentally deploying to production with those local scripts. It might not be technically feasible to "automatically" support both use-cases without some configuration

[dexhorthy]

Gotcha, makes sense. I hadn't thought about wanting to limit a k8s context when local might be used to invoke kubectl/helm commands but that definitely makes sense.

I guess my concern that if I whitelist all k8s contexts that I might accidentally deploy to prod someday is not really at play here since I'm just using this tiltfile for running unittests for a CLI tool.

I do have calls to local, for reference here's the full Tiltfile:

# vi: set ft=python
#
packages = local('go list ./pkg/... ./cli/... ./client/...')

for package in str(packages).split():
    short_name = "-".join(package.split("/")[-2:])
    local_resource('test-%s' % short_name, cmd='go test %s' % package, deps=['./'])

[maiamcc]

I guess my concern that if I whitelist all k8s contexts that I might accidentally deploy to prod someday is not really at play here since I'm just using this tiltfile for running unittests for a CLI tool.

maybe I'm missing something but how is whitelisting all contexts any riskier than skipping the context check? (Or I guess a better question is: how would you ideally like this to work / what would feel safest to you?)

[landism]

maybe I'm missing something but how is whitelisting all contexts any riskier than skipping the context check? (Or I guess a better question is: how would you ideally like this to work / what would feel safest to you?)

In both dex's question and #3615, there are no k8s resources. If we could only enforce the check on local for Tiltfiles that define k8s resources, then if someone were to add a k8s resource while pointed at a prod cluster, the check would activate and protect them.

A couple of issues with that:

1. At the time the local executes, Tilt doesn't know if there's a k8s resource declared later in the Tiltfile
2. Even in a case where a Tiltfile has no k8s resources, a local could still be running kubectl commands

I think it's worth adding a local arg that specifies it's safe to run in any context (and then potentially an option to make that the default for the Tiltfile, if it proves popular).

[jtamagnan]

I think it's worth adding a local arg that specifies it's safe to run in any context

Agreed, this would be a perfect solution for me. There are some functions that use local that I would like to run when a file is first loaded so that I can cache the output. If I want to load this file I need to have first allowed the k8s context which feels off. I'd like to have all of my imports top level.

Something like this wouldn't work:

# /Tiltfile
load("/subdir/Tiltfile", cached_value)
load(...)
load(...)

allow_k8s_contexts(...)

# /subdir/Tiltfile
cached_value = local(...)