It would be nice to do something like: tilt config set registryName hausdorff and then be able to reference registryName throughout the Tiltfile. This would really cut down on the number of caveats the demo has.

I've got a fairly ordinary deployment with an associated image, which I can add to my Tiltfile and everything works as expected.

k8s_yaml('uses-my-image.yaml')
docker_build('my-image', 'my-image-repo')

However, my-image is based on another image that I am actively developing. But when I try this Tiltfile:

k8s_yaml('uses-my-image.yaml')
docker_build('my-base-image', 'my-base-image-repo'')
docker_build('my-image', 'my-image-repo')

I get this error:
image my-base-image is not used in any resource

It would be cool if Tilt could detect that my-image is based on my-base-image via its FROM clause, and:

1. rebuild both images, in the correct order, when my-base-image changes
2. rebuild just my-image when only it has changed

Tilt's behavior changes depending on whether it thinks your kube context refers to a local cluster (docker ofr mac, minikube, microk8s) or a remote cluster. Right now you have to infer which Tilt thinks it is running in based off of if its trying to push an image to a remote registry, among other things.

I think we should log in to the Tiltfile log whether Tilt thinks the given kubecontext is local or remote.

Discussed in the Tile channel in Kubernetes slack

Users want to use the same tool for local dev and CI. Using skaffold or draft supports this.

Tilt could have a mode that is meant for CI.

It actually does this today, if you run tilt up --hud=false --watch=false, but this doesn't give much confidence that we intend to support this.

Hi, I was reading through the beginner docs and noticed that it said to verify the version by typing tilt version.

I receive the following response:

> tilt version
template engine not found for: version

After pulling down the latest tilt source I ran tilt up from integration/oneup, but ran into a problem when tilt tries to push the docker image. I don't have that auth config file to push.

Some users may have yaml that includes images they want built/injected that's not in a field named image. Tilt could find these, perhaps with extra configuration.

Tilt currently knows how to find images defined in "containers" for stock k8s types, but if a CRD specifies an image (even if it's using standard container syntax), Tilt doesn't know what to do with it.

When Tilt compiles inside a container, it sometimes fails with exit code 137. This typically means that Kubernetes evicted it for some reason (out of memory or out of cpu are possibilities).

When this happens, Tilt should fallback to building outside the container rather than treating it as a compile error.

https://docs.tilt.build/api.html#api.k8s_yaml

this doc says that you should be able to pass in a string of yaml, but this does not actually work. it only accepts a file path or a blob.

not sure if the API should be changed to accept a string, or if there should be some other function that parses a string into a form that k8s_yaml recognizes

It looks like if two --- separators are grouped together in a yaml file provided to tilt, this causes a runtime error.

I'm seeing this on tilt built from master, version info: v0.0.0-dev, built 2018-12-22

This is a minimal configuration which should reproduce the issue:

# TiltFile
k8s_yaml(local("echo '---\n---'"))

tilt up output:

Error: Object 'Kind' is missing in '---
': Object 'Kind' is missing in '---
'

In my use case, I'd like to be able to use tilt along with existing helm charts. The helm template command seems like a nice way to integrate with tilt, but its output always includes a separator and yaml comment for each source template, regardless of whether the rendered contents of that template include a valid resource.

For example, rendering the stable/redis chart with metrics disabled results in this partial yaml:

---
# Source: redis/templates/metrics-deployment.yaml


---
# Source: redis/templates/metrics-prometheus.yaml

---
# Source: redis/templates/metrics-svc.yaml

With the helm cli installed, you can reproduce this with the following configuration:

# TiltFile
k8s_yaml(local("helm fetch stable/redis --version 5.1.3 --untar --untardir tmp && helm template tmp/redis --name test"))

Hey,

I am trying to use tilt in my current environment:
Windows 10 host machine using WSL to run Ubuntu 18.04.
Everything works great so far, only feature that is buggy is the file watch, and auto build+deploy. This seems to be known issue with WSL not fully implementing inotify. There is also more related information in VS Code Repo.

I don't think this is something tilt can (or should) solve, but in order to still use tilt features in an environment that does not support it would be nice to have a force rebuild & deploy in the HUD, just like can be used to manually to a rebuild (for changed) components, it would be nice to have a force rebuild shortcut as well!

Any thoughts / ideas appreciated!
Cheers,
Datosh

First of all I would like to thank you for sharing this awesome project :)

I have some interesting use-cases of which some where supported and some I was not able to get working. We can use this issue to have a general discussion.

We have 10s of helm charts for various projects, hosted in a centralized repository (separate from the source) and served through chartmuseum. This is quite a common workflow in the community. Much similar to the community supported helm charts repo. A helm chart can be a combination of deployments, statefulsets and CRDs for various microservices. We also have environment specific values bundled inside helm charts called profiles, to make them portable independent deployment units. A centralized helm chart repo roughly looks something like this:

    kubernetes-charts
    ├── stable
    │   ├── project-x
    │   │   ├── profiles
    │   │   │   ├── production
    │   │   │   │   ├── eu-central-1
    │   │   │   │   │   ├── secrets.yaml
    │   │   │   │   │   ├── values.yaml
    │   │   │   │   │   └── sops.yaml
    │   │   │   │   └── us-east-1
    │   │   │   │       ├── secrets.yaml
    │   │   │   │       ├── values.yaml
    │   │   │   │       └── sops.yaml
    │   │   │   └── dev
    │   │   │       ├── eu-central-1
    │   │   │       ├── secrets.yaml
    │   │   │       ├── values.yaml
    │   │   │       └── sops.yaml
    │   │   ├── templates
    │   │   │   ├── _helpers.tpl
    │   │   │   ├── Notes.txt
    │   │   │   ├── microservice
    │   │   │   │   ├── deployment.yaml
    │   │   │   │   ├── configmap.yaml
    │   │   │   │   ├── service.yaml
    │   │   │   │   ├── ingress.yaml
    │   │   │   │   ├── prometheusrule-recordingrules.yaml
    │   │   │   │   ├── prometheusrule-alerts.yaml
    │   │   │   │   └── servicemonitor.yaml
    │   │   │   ├── dashboards
    │   │   │   │   └── configmap.yaml
    │   │   ├── dashboards
    │   │   │   ├── grafana-dashboard-mydashboard.json
    │   │   │   └── grafana-dashboard-myotherdashboard.json
    │   │   ├── chart.yaml
    │   │   ├── README.md
    │   │   └── values.yaml
    ├── README.rst
    ├── CONTRIBUTING.rst
    ├── Makefile
    └── Jenkinsfile

My first problem was with supporting remote helm charts with helm(pathToChartDir). But that was easily solvable through the addition of local command and using helm template command. So my tiltfile looks something like this for fetching the helm charts and rendering them properly with secrets, release names, namespaces etc for a typical project:

# Typically we add these defaults in to Makefile for each projects src repo.
# Getting these from Makefile directly would be awesome
pip_index_url = "https://some-private-pypi-repo/simple"
docker_registry = "private-registry.com"
namespace = "myProject"
project_short = "mp"

# Generate release name based on calling user identity
# We have aws IAM identities mapped to k8s users
caller_identity = str(local("aws sts get-caller-identity"))

# Not sure if one can parse json in starlark, but this is a quick hack, but you get a nice release name for a dev working on his instance of application
# Release names are embedded in k8s objects labels, names etc, to differentiate various instances of application running in the same namespace
caller_identity = caller_identity[caller_identity.find("user/") + 5:len(caller_identity) - 4]
release_name = "{}-{}".format(project_short, caller_identity)

# We fetch a helm chart, untar locally and get the profiles with development values
template_script = "helm fetch stable/myProject --untar --untardir ./deploy/helm/ && helm template ./deploy/helm/myProject --namespace {} --name {} -f ./deploy/helm/myProject/profiles/development/eu-central-1/values.yaml".format(namespace, release_name)
yaml_blob = local(template_script)

# Quick docker builds for working on each individual microservice
# Each microservice is a separate folders in root path of the project source repo
# Python component
docker_build(cosmo_image, "cosmo", dockerfile="./cosmo/Dockerfile", build_args={"PIP_INDEX_URL": pip_index_url})
# Python component
docker_build(serving_image, "serving", dockerfile="./serving/Dockerfile", build_args={"PIP_INDEX_URL": pip_index_url})
# Rust component
docker_build(simq_image, "simq", dockerfile="./simq/Dockerfile")

# This is where the problem starts. My first try was to add just a k8s_resource with rendered blob 
k8s_resource("myProject", yaml_blob, port_forwards=8080)

Now all my microservice manifests are bundled in to one big rendered yaml blob, rather than separate k8s manifests per microservice as shown above. It would be rather difficult to separate them in to separate yamls as they are bundled into one umbrella chart and those are pretty complex. Most of the examples showcase separate yamls per microservice and having separate k8s_yaml statements.

This has an unintended consequence in accordance with the above script that everything shows up under a single name in the UI. All microservices build nicely and are published properly with tilt generated tags, but the pod names change when there are logs streamed from it and then it is not really a nice UX.

Another problem how can we do port_forward per microservice/pod. Does not seems to be possible with my current implementation.

Another problem is with image name and tags and how we typically define them in helm charts. We use a format in spec:

    spec:
      containers:
          image: {{ .Values.microservice_name.image.repository }}:{{ .Values.microservice_name.image.tag }}

And supply these with different values files based on environment. These seems to be a similar issue to #1059. There is a colon which is part of the template and a tag is injected externally based on environment (in this case development) and leads to a cryptic error:

Error: image registry/project/microservice is not used in any resource

Removing all the tags from the templates and making the image name the same as the ref. Seems to work but is not useful anymore. It would be nice to have a scenario, where by some microservices are locked to a specific version which can be stable, and others which one is working on will have there tags automatically generated by tilt or even passed in by a custom function written in titfile to comply with different tagging notations. These can important because we have certain lifecycle rules on docker registry to cleanup images and then can be different from tilt tagging format. But this is a small nit pick.

Also sometimes I have seen during incremental updates to code and restarting/spawning of new pods the ui loses track of which pod is the current running pod and will still try to get logs of a non existent pod and will fail continuously.

In other cases during network failures from client machine or an elb in front of the api server closing long running tcp connections, logs are no longer being streamed or retried and you get a nice EOF message.

These are some of the things I have seen from my experience, from a day of playing with tilt. If you need more context or support I can certainly provide some. I would definitely like to figure out the big helm chart deployment and tagging problems. Thanks again for the awesome tool :)

Sweet project! I'm trying to use it and add a Homebrew formula, but running into a problem with dependencies.

$ brew install tilt
==> Downloading https://github.com/windmilleng/tilt/archive/v0.5.1.tar.gz
Already downloaded: /Users/adam/Library/Caches/Homebrew/downloads/4b14482ba8f095cf812f418b4fccde23ec0e0b7c9d7458e9c21888a24e5ee897--tilt-0.5.1.tar.gz
==> ./hide_tbd_warning go install ./...
Last 15 lines from /Users/adam/Library/Logs/Homebrew/tilt/01.hide_tbd_warning:
internal/tiltfile/files.go:13:2: cannot find package "github.com/windmilleng/tilt/internal/kustomize" in any of:
	/usr/local/Cellar/go/1.11.4/libexec/src/github.com/windmilleng/tilt/internal/kustomize (from $GOROOT)
	/Users/adam/Library/Caches/Homebrew/go_cache/src/github.com/windmilleng/tilt/internal/kustomize (from $GOPATH)
internal/tiltfile/tiltfile.go:9:2: cannot find package "go.starlark.net/resolve" in any of:
	/usr/local/Cellar/go/1.11.4/libexec/src/go.starlark.net/resolve (from $GOROOT)
	/Users/adam/Library/Caches/Homebrew/go_cache/src/go.starlark.net/resolve (from $GOPATH)
internal/tiltfile/docker.go:9:2: cannot find package "go.starlark.net/starlark" in any of:
	/usr/local/Cellar/go/1.11.4/libexec/src/go.starlark.net/starlark (from $GOROOT)
	/Users/adam/Library/Caches/Homebrew/go_cache/src/go.starlark.net/starlark (from $GOPATH)
internal/tracer/tracer.go:14:2: cannot find package "github.com/openzipkin/zipkin-go-opentracing" in any of:
	/usr/local/Cellar/go/1.11.4/libexec/src/github.com/openzipkin/zipkin-go-opentracing (from $GOROOT)
	/Users/adam/Library/Caches/Homebrew/go_cache/src/github.com/openzipkin/zipkin-go-opentracing (from $GOPATH)
internal/watch/watcher_darwin.go:8:2: cannot find package "github.com/windmilleng/fsevents" in any of:
	/usr/local/Cellar/go/1.11.4/libexec/src/github.com/windmilleng/fsevents (from $GOROOT)
	/Users/adam/Library/Caches/Homebrew/go_cache/src/github.com/windmilleng/fsevents (from $GOPATH)

READ THIS: https://docs.brew.sh/Troubleshooting

Mac OS 10.13.3 (17D47)
go version go1.11.1 darwin/amd64
Docker version: 18.09.0, API version: 1.39

New Mac users following the first example guide will encounter issues requiring some troubleshooting:

• If the user opted for the curl method of installing Tilt in the Tilt installation guide, the "tilt up" command on the first example guide throws an error:

ERROR: ImageBuild: failed to create LLB definition: Dockerfile parse error line 1: unknown instruction: PAXHEADERS.0 0000000 0000000 0000000 00000000044 00000000000 010142

However, docker build . on the Dockerfile present in tilt/integration/oneup successfully builds the image. Using the go get method of installing Tilt allows you to successfully build the image with tilt up.

• Once the image is built, it attempts to push an image to GCR to which the user may not have access by default.

ERROR: pushing image "gcr.io/windmill-test-containers/integration/oneup": unauthorized: You don't have the needed permissions to perform this operation, and you may have invalid credentials. To authenticate your request, follow the steps in: https://cloud.google.com/container-registry/docs/advanced-authentication

A Google account is not listed as a prerequisite. Even if it were, new users should not be pushing to a shared registry. To get past this error, the user must:

1. Go to https://console.cloud.google.com/gcr/images/windmill-test-containers/ and log in with Google credentials to obtain the pull command/tag ID from the most recent push (because there is no "latest" tag)
2. Pull the image down
3. Tag the pulled image in order to push it to their container registry of choice
4. Update the Tiltfile to reflect the new image location
5. Update the oneup.yaml to reflect the new image location

Then tilt up is successful and the user can proceed.

Tilt should have build in support for setting a Kubernetes namespace that all objects get created in for the duration of the session.

Tiltfile syntax could look like this:

set_namespace("dan-dev")

Tilt would remember the namespace that you specify and append it as a command line flag every time it invokes kubectl.

It would be great if Tilt supported basic file operations like creating files and checking files exist in addition to reading files.

While it is possible to do these things with local supporting them in Tilt makes it easy for us to mark files that are interacted with in this way as dependencies.

This came in via #tilt in Kubernetes slack.

Just downloaded tilt via the instructions and attempted to run the example program.

> curl -L https://github.com/windmilleng/tilt/releases/download/v.4.1/tilt.0.4.1.mac.x86_64.tar.gz | tar -xzv tilt && sudo mv tilt /usr/local/bin/tilt
... curl stuff ...
> git clone https://github.com/windmilleng/tilt
... git stuff ...
> tilt version
Send anonymized usage data to Windmill [y/n]? y
Thanks! Setting 'tilt analytics opt in'
You set can update your privacy preferences later with 'tilt analytics'
v0.4.1, built 2019-01-07
> cd tilt/integration/oneup
> tilt up
Error: error initializing renderer: terminal entry not found
> echo $TERM
xterm-color

I'm using iTerm2 as my terminal, but I get the same results in the built-in Terminal.app.

What should I check?

A la Bazel's fail function.

@thrawny in Kubernetes slack brought this up to make it easier to check things about the environment and fail if certain conditions aren't true. I've always found needs for this.

Hi,

I'd like to start off my Tiltfile with a few base services which my cluster depends on, and I would like to set up port forwarding as well. So far the file is pretty simple, yet it runs into a problem.

# dgraph
k8s_resource('dgraph', './dgraph/single.yaml', port_forwards=[8080, 9080, 8000, 5080, 6080])

# fusionauth
k8s_resource('fusionauth', kustomize('fusionauth-infrastructure/kubernetes'), port_forwards=[9011])

# kill-bill setup
k8s_resource('killbill', kustomize('killbill'), port_forwards=[9090, 8080, 8000, 12345])

The errors reported are:

──┤ Building: dgraph ├──────────────────────────────────────────────
Build Failed: ImageBuildAndDeployer does not support these specs

──┤ Building: fusionauth ├──────────────────────────────────────────────
Build Failed: ImageBuildAndDeployer does not support these specs

──┤ Building: killbill ├──────────────────────────────────────────────
Build Failed: ImageBuildAndDeployer does not support these specs

I also tried running the installs at the beginning via k8s_yaml but then the k8s_resource doesn't find it:

k8s_yaml('./dgraph/single.yaml')
k8s_resource('dgraph', port_forwards=[8080, 9080, 8000, 5080, 6080])

--- results in:
Tiltfile error:
resource "dgraph": no matching resource

Can such "ready-made" services be deployed before my development packages are built?

When using a Tiltfile with

k8s_yaml(helm("./charts/nginx-ingress"))

and the nginx-ingress is the chart from https://kubernetes-charts.storage.googleapis.com

when running tilt up I get this response..

Any Ideas?.
I've tried using k8s_yaml(local("helm template -n dodgy-release ./charts/nginx-ingress")
and this will generate valid information, but the specified release-name does not match the generated one, so the linkages are broken.

RELEASE-NAME-nginx-ingress-controller (ConfigMap)
      RELEASE-NAME-nginx-ingress (ServiceAccount)
      RELEASE-NAME-nginx-ingress (ClusterRole)
      RELEASE-NAME-nginx-ingress (ClusterRoleBinding)
      RELEASE-NAME-nginx-ingress (Role)
      RELEASE-NAME-nginx-ingress (RoleBinding)
      RELEASE-NAME-nginx-ingress-controller (Service)
      RELEASE-NAME-nginx-ingress-default-backend (Service)
      RELEASE-NAME-nginx-ingress-controller (Deployment)
      RELEASE-NAME-nginx-ingress-default-backend (Deployment)
    ERROR:
       Error: Error upserting global_yaml: kubectl apply:
       stderr: Error from server (Invalid): error when creating "STDIN": ConfigMap "RELEASE-NAME-nginx-ingress-controller" is invalid: metadata.name: Invalid value: "RELEASE-NAME-nginx-ingress-controller": a DNS-1123 subdomain must
       consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is
       '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')
       Error from server (Invalid): error when creating "STDIN": ServiceAccount "RELEASE-NAME-nginx-ingress" is invalid: metadata.name: Invalid value: "RELEASE-NAME-nginx-ingress": a DNS-1123 subdomain must consist of lower case
       alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')
       Error from server (Invalid): error when creating "STDIN": ClusterRoleBinding.rbac.authorization.k8s.io "RELEASE-NAME-nginx-ingress" is invalid: subjects[0].name: Invalid value: "RELEASE-NAME-nginx-ingress": a DNS-1123 subdomain
       must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is
       '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')
       Error from server (Invalid): error when creating "STDIN": RoleBinding.rbac.authorization.k8s.io "RELEASE-NAME-nginx-ingress" is invalid: subjects[0].name: Invalid value: "RELEASE-NAME-nginx-ingress": a DNS-1123 subdomain must
       consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is
       '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')
       Error from server (Invalid): error when creating "STDIN": Service "RELEASE-NAME-nginx-ingress-controller" is invalid: metadata.name: Invalid value: "RELEASE-NAME-nginx-ingress-controller": a DNS-1035 label must consist of lower
       case alphanumeric characters or '-', start with an alphabetic character, and end with an alphanumeric character (e.g. 'my-name',  or 'abc-123', regex used for validation is '[a-z]([-a-z0-9]*[a-z0-9])?')
       Error from server (Invalid): error when creating "STDIN": Service "RELEASE-NAME-nginx-ingress-default-backend" is invalid: metadata.name: Invalid value: "RELEASE-NAME-nginx-ingress-default-backend": a DNS-1035 label must consist
        of lower case alphanumeric characters or '-', start with an alphabetic character, and end with an alphanumeric character (e.g. 'my-name',  or 'abc-123', regex used for validation is '[a-z]([-a-z0-9]*[a-z0-9])?')
       Error from server (Invalid): error when creating "STDIN": Deployment.apps "RELEASE-NAME-nginx-ingress-controller" is invalid: [metadata.name: Invalid value: "RELEASE-NAME-nginx-ingress-controller": a DNS-1123 subdomain must
       consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is
       '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*'), spec.template.spec.serviceAccountName: Invalid value: "RELEASE-NAME-nginx-ingress": a DNS-1123 subdomain must consist of lower case alphanumeric characters, '-'
        or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')]
       Error from server (Invalid): error when creating "STDIN": Deployment.apps "RELEASE-NAME-nginx-ingress-default-backend" is invalid: metadata.name: Invalid value: "RELEASE-NAME-nginx-ingress-default-backend": a DNS-1123 subdomain
       must consist of lower case alphanumeric characters, '-' or '.', and must start and end with an alphanumeric character (e.g. 'example.com', regex used for validation is
       '[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*')

Tilt builds images and then injects them into kubernetes objects. Today, it supports only one image per kubernetes object. (This limitation came about with how we group work so we can group errors to make a more useful UX). If you have a Kubernetes object with multiple images, but Tilt only builds one, everything's fine.

Tilt should support building multiple images and injecting them into one object (e.g. a Deployment with several containers).

We're working on it, and it should be here in a bit, so this is a good issue to follow if you want it.

Various projects (e.g., npm) have an init or new command that asks you a series of questions and then generates the relevant files (e.g., package.json) in response.

It would be very nice if something similar was available with tilt.

In your oneup tutorial, the Go code opens up a port, and tilt does report that something is running on a port:

oneup ┊ 2018/12/19 06:57:45 Serving oneup on 8000

However, it is not available on localhost:8000.

Thanks.

I'm noticing that using fast_build.add I'm always getting ADD . / in the logs, no matter what arguments I pass into fast_build.add. It's pretty minor since it appears everything does get copied in as expected, it was just confusing. I would expect to see something like ADD /path/to/source /path/in/container.

> tilt version
v0.4.2, built 2019-01-09

As mentioned by @moltar, it could be cool to show each request in the log of the oneup service. This would help reinforce that when you hit that port it is being directed to that service, and gives you something to look at in the log pane from the get-go.

Will tilt work on microk8s? I'm on a spotty internet connection, haven't been able to git clone the example tilt app to try tilt via KUBECONFIG env var.

I did try this, which didn't work likely because the context is not recognized...

$ tilt demo
tilt demo mode only supports Docker For Mac or Minikube
check your current cluster with:

kubectl config get-contexts

$ microk8s.kubectl config current-context
microk8s

I had setup KUBECONFIG env this way:

$ microk8s.kubectl config view --raw > ~/.kube/config
$ set -x KUBECONFIG ~/.kube/config   # fish shell

Right now Tilt respects both the .gitignore and .dockerignore files for triggering builds and for including files in the build context. This isn't flexible enough for complex projects where you might want to exclude different files in development than you would in production.

We should support some way of specifying which files can't trigger builds.

Open question: should they then be included in the build?

Right now cron jobs are surfaced oddly in the UI: they are always marked as pending. We should have a better UX around this.

There are many ways that people can install docker or kubectl: be it docker for mac, gcloud, or something else. If you already have these things installed and you install Tilt with homebrew you get errors that suggest that the install failed, even if it succeeded:

The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink bin/docker
Target /usr/local/bin/docker
already exists. You may want to remove it:
  rm '/usr/local/bin/docker'

The `brew link` step did not complete successfully
The formula built, but is not symlinked into /usr/local
Could not symlink bin/kubectl
Target /usr/local/bin/kubectl
already exists. You may want to remove it:
  rm '/usr/local/bin/kubectl'

Technically we don't depend on kubectl now with docker compose support anyways. Maybe we should just remove all dependencies and add a message advising users about what they should install?

Maybe there's a way to check if a dependency is fulfilled somehow in Homebrew?

@thrawny in Kubernetes Slack had production downtime caused by inadvertently allowing Tilt to deploy dev configs to a production Kubernetes cluster. This is something we'd very much like to avoid happening to others.

A use case we want to support is for people to run Tiltfiles with a large number of services against a Kubernetes cluster that exists in the cloud, so that their laptop doesn’t melt. For this use case the kubecontext could be anything. However, it's my believe that comparatively few people are using Tilt in this way.

I think we should disable deploying to non-local (minikube, docker-for-mac, possibly others) kubecontexts by default. If Tilt is started with such a non-local kubecontext we could display a message like this:

It looks like you're running Tilt against a remote Kubernetes cluster (KUBECONTEXT_NAME_HERE). Tilt supports this, but we want to make sure you're not inadvertently deploying to prod! To enable remote Kubernetes deploys simply add `enable_remote_deploy()` to your Tiltfile.

Perhaps if you are using a remote kubecontext and you haven't set enable_remote_deploy() we still perform other local operations (docker builds, locals)?

I would love other's thoughts! @thrawny let me know if I got any details wrong.

A pattern for image building is to have one "common" image, which your "app" images build on.

This means that the common image can be a dependency of more than one set of k8s_resource.

Currently, Tilt does not support this well, but should.

TLDR, we need to change ManifestNameForTargetID to return multiple consumers for one build target

Just thought it would be nice if there was a step in-between the smallest log expansion and full screening it. Maybe like half the screen.

I'm trying to resolve a Kubernetes internal dns record like fed.apps.svc.cluster.local, but am having issues doing so.

My setup is Docker for Mac (2.0.0.3), which ships with Docker 18.09.02 and Kubernetes v1.10.11.

The Tiltfile I'm using is pretty basic, each Kubernetes file has a Deployment, Ingress, etc copied from our production setup.

k8s_yaml("00-namespace.yml")

k8s_resource('proxy', './proxy/proxy.yml', port_forwards='9000:9000')
k8s_resource('ach', './ach/10-ach.yml', port_forwards='8080:8080')
k8s_resource('auth', './auth/11-auth.yml', port_forwards='8081:8080')
k8s_resource('ofac', './ofac/13-ofac.yml', port_forwards='8084:8080')
k8s_resource('paygate', './paygate/12-paygate.yml', port_forwards='8082:8080')

When I try and load http://localhost:9000/v1/fed/ping I get back a 502 error with the following from the proxy pod (running a Go HTTP reverse proxy).

2019/03/14 18:16:42.956286 reverseproxy.go:442: http: proxy error: dial tcp: lookup fed.apps.svc.cluster.local on 10.96.0.10:53: no such host

I've looked through the kubedns logs and everything looks okay. Is this a known issue?

Right now we decide whether a cluster is local via safe list of kube context names. You could always rename one of these kube contexts to something else, so we should allow people to override this list from the Tiltfile.

Could be something as simple as:

assume_local_kube_context()

Or

set_local_kube_context(context_name)

Or could our detection of local vs remote kubecontexts be more sophisticated?

Slightly related to #1096.

Discussed in #Tilt channel on Kubernetes slack.

Tags in images (e.g. registry.tld/path/image:1) do not work in tilt. It will complain that image registry.tld/path/image is not used in any resource. Even if I run: docker_build("registry.tld/path/image:1", ".")`. This is a show stopper for us because we would have to change all helm charts to use it.

I have a setup where an image is used for two purposes - (i) standard server via Deployment and (ii) migration via Job. The image is built by tilt and both k8s resources use the same image. Tilt groups both the deployment and job together and then monitors the job, which eventually completes. Below is a simplified example:

Tiltfile

k8s_yaml(['deployment.yaml', 'job.yaml'])
docker_build('tilt', '.')

Dockerfile

FROM nginx:alpine
WORKDIR /
COPY start.sh /start.sh
ENTRYPOINT ["/start.sh"]
CMD ["pod", "nginx", "-g", "daemon off;"]

start.sh

#!/bin/sh

MODE=$1; shift

if [ "$MODE" = "job" ]; then
    echo "Running job..."
    sleep 10
    echo "Job done"
    exit 0
fi

exec "$@"

job.yaml

apiVersion: batch/v1
kind: Job
metadata:
  name: tilt-job
spec:
  template:
    spec:
      containers:
      - name: tilt-job
        image: tilt:test
        args: ["job"]
      restartPolicy: Never
  backoffLimit: 0

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tilt
  labels:
    app: tilt
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tilt
  template:
    metadata:
      labels:
        app: tilt
    spec:
      containers:
      - name: tilt
        image: tilt:test
        ports:
        - containerPort: 80

kubectl log output:

kubectl logs tilt-767c9bb6cb-fp4l6
10.1.1.1 - - [06/Mar/2019:17:42:01 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.58.0" "-"
kubectl logs tilt-job-n5txm
Running job...
Job done

Tilt

  RESOURCE NAME                                                              DEPLOY •    BUILD STATUS •  UPDATED
▶ ● tilt ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ Completed • OK       (1.6s) •   2m ago
  ● (Tiltfile) ╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌ N/A             •   2m ago

Tilt logs output

Starting Tilt (v0.7.6-dev, built 2019-03-06)…
[Tiltfile] 2019/03/06 09:41:07 Beginning Tiltfile execution

[Tiltfile] 2019/03/06 09:41:07 Successfully executed Tiltfile


──┤ Building: tilt ├──────────────────────────────────────────────
STEP 1/2 — Building Dockerfile: [docker.io/library/tilt]
  │ Tarring context…
    ╎ Created tarball (size: 6.7 kB)
  │ Building image
    ╎ [1/2] FROM docker.io/library/nginx:alpine
    ╎ [2/2] COPY start.sh /start.sh

STEP 2/2 — Deploying
  │ Parsing Kubernetes config YAML
  │ Applying via kubectl

  │ Step 1 - 1.157s
  │ Step 2 - 0.424s
  │ Done in: 1.581s

In my actual setup the results were a bit different initially. I had 4 containers in my job, each of which used a different Tilt-controlled image. In this case, I actually lost resources in the Tilt display as a result of adding them. Splitting the job out to 4 jobs fixed that, but still have the monitoring issue.

Hey, found your cool project via HN and decided to run through the getting started guide, but immediately ran into a couple deal-breaking issues that I assume are related to each other:

Sometimes while running (idle or otherwise), tilt seems to consume about 75-150 %CPU as reported by top, and on top of that causes my terminal to eat another 75%, and if inside tmux, another 75% for the tmux server! That's quite a bit for a single tool sitting in an idle state.

In addition, when running in tmux, my cursors in other panes seem to flicker rapidly at the same time of the CPU usage spikes, suggesting the cause might be unnecessarily frequent repainting by tilt.

Not sure what info would be helpful, but I'm running tilt version v0.4.1, built 2019-01-07, Ubuntu 18.10, tmux 2.7 and GNOME Terminal 3.33.1.

Hey

As per subject, I just ran into this issue:

>> tilt up
Error: No Auth Provider found for name "oidc"

My local kubeconfig has my user configured to use an OIDC auth provider.

I think this is usually resolved by importing the following:

import (
     _ "k8s.io/client-go/plugin/pkg/client/auth/oidc"
)

I'm not sure where the error is coming from, maybe ./k8s/portforward.go (there's some related gcp auth support there).

Thanks

Specifically for the use case of enumerating a bunch of dependencies in a Helm chart directory and read_file'ing them to add them as dependencies to a Tilt run.

reported in the #tilt k8s channel by jaucon. I can repro the issue

Repro steps:

• Start minikube
• Follow the instructions at https://jeremievallee.com/2018/05/28/kubernetes-rbac-namespace-user.html on creating a user with limited permissions, and dump it in a custom kubeconfig
• start Tilt as

KUBECONFIG=/path/to/custom/.kubeconfig tilt up

Result: Tilt fails with the error

Error: Error watching services. Are you connected to kubernetes?
: unknown (get services)

Note that I can run

KUBECONFIG=/path/to/custom/.kubeconfig kubectl get services

without problems

We use Bazel and a combination of rules_k8s and rules_docker to build Kube manifests and Docker images. Right now, we have some hacky shell scripts that developers need to run manually to actually deploy to a local k8s cluster.

Bazel already gives us fast image builds, and fast loading to the local Docker instance or remote registry. However, Tilt would really improve the UX of deploying and iterating locally.

To that end, I've managed to replace the aforementioned shell scripts with Tilt in this Tiltfile proof-of-concept. It rips off a technique used by bazel-watcher:

BAZEL_RUN_CMD = "bazel run %s"

BAZEL_SOURCES_CMD = """bazel query 'kind("source file", deps(set(%s)))'"""

BAZEL_BUILDFILES_CMD = "bazel query 'buildfiles(deps(set(%s)))'"

def bazel_k8s(target):
    """Get YAML and dependencies from a k8s_object or similar Bazel target.

    Args:
        target (str): An executable Bazel target that outputs YAML when run.

    Returns:
        str: The YAML or other output from running the target.
        list: Source files and BUILD/WORKSPACE files that the target depends on.
    """
    yaml = local(BAZEL_RUN_CMD % target)

    dep_labels = str(local(BAZEL_SOURCES_CMD % target)).splitlines()
    dep_labels += str(local(BAZEL_BUILDFILES_CMD % target)).splitlines()

    dep_files = {}
    for l in dep_labels:
        if l.startswith("@"):
            continue
        elif l.startswith("//external/") or l.startswith("//external:"):
            continue
        elif l.startswith("//"):
            l = l[2:]

        path = l.replace(":", "/")
        dep_files[path] = None

    return yaml, dep_files.keys()

yaml, files = bazel_k8s("//my_service:k8s")

# apply yaml to the k8s cluster
k8s_yaml(yaml)

# tell Tilt about dependencies
for f in files:
    read_file(f)

However, it'd be great to have a native implementation of the bazel_k8s function. Ideally it would use Bazel's protobuf-based Go API, rather than just parsing the normal stdout like in the example above.

A common idiom in Docker image names is to have different tags for different operating systems, e.g.

docker_build('common:alpine', '../common', dockerfile='../common/docker/Dockerfile')
docker_build('common:jessie', '../common', dockerfile='../common/docker/jessie/Dockerfile')

Currently Tilt does not support this, but should. It will often build the wrong image, do something non-deterministic, or blow up with errors.

Very cool tool! I'm excited to get it working for the dev team at my company.

I was able to run the example from the tutorial but am running into an issue running tilt up with a Tiltfile that references my company's private image repository on GCR. Here's my Titlefile (with registry name details redacted):

# -*- mode: Python -*-

docker_build('us.gcr.io/company_repo/test_app:latest', '../../testing')
k8s_resource('tilt_testing', './production/test-deployment.yaml', port_forwards=3002)

And here's what happens when I run tilt up:

I've followed the instructions from the error message (https://cloud.google.com/container-registry/docs/advanced-authentication) and all of the configurations completed successfully, but they didn't help the issue. I have no issues pulling/pushing to that repository with other docker commands outside of Tilt.

Thanks in advance for your assistance!

Expect:
tilt demo to come up. How to fix it?

Actual:
1.39 API error from docker

Steps:

  pi@node00:~/go/bin $ docker version
Client:
 Version:           18.06.1-ce
 API version:       1.38
 Go version:        go1.10.3
 Git commit:        e68fc7a
 Built:             Tue Aug 21 17:30:52 2018
 OS/Arch:           linux/arm
 Experimental:      false

Server:
 Engine:
  Version:          18.06.1-ce
  API version:      1.38 (minimum version 1.12)
  Go version:       go1.10.3
  Git commit:       e68fc7a
  Built:            Tue Aug 21 17:26:37 2018
  OS/Arch:          linux/arm
  Experimental:     false
pi@node00:~/go/bin $ tilt demo
Error: newDockerClient: Error response from daemon: client version 1.39 is too new. Maximum supported API version is 1.38
pi@node00:~/go/bin $ whereis tilt
tilt: /home/pi/go/bin/tilt

step 1: run tilt

If you run tilt up and then switch kubernetes context in another terminal session then tilt will start working in that context instead. This is somewhat scary as I did tilt up and then switched to our production context and was looking at things there, having forgotten that tilt was still running.

Can we make tilt definitely stay on the same context, or pass in the context we want to use as an argument to tilt up? What do you think? I would be happy to contribute if you think it is a good idea.

I know I could use the KUBECONFIG environment variable as a workaround. Maybe alias tilt like so:

alias tilt="KUBECONFIG=/path/to/devcfg/ tilt"

But I think it would be nice if this was supported natively.

Is there any example that integrates with helm ?

Originally when I got started with the servantes demo, it took me about an hour before I realized that the image name in fast_build has to be the same as the name passed k8s_resource. See code snippet below. I'm still not sure why this is necessary (so you can link them together in the UI?), but either way, might be worth making this link more explicit somehow, perhaps by having one of them take the other as an argument.

(fast_build('hausdorff/servantes-fe',
            'Dockerfile.go.base', '/go/bin/fe --owner ' + get_username())
  .add(repo.path('fe'), '/go/src/github.com/windmilleng/servantes/fe')
  .run('go install github.com/windmilleng/servantes/fe'))

k8s_resource('servantes-fe', port_forwards=port)

Hey, just found this project, it looks really neat!

Any thoughts on kubefwd integration? Is there one? Does that even make sense? Would there be a workflow that would make sense today?

When I have two build-args, both end up set with the same value.

docker_build('tilt', '.', {'KEY1': 'key1', 'KEY2': 'key2'}) => KEY1=key2, KEY2=key2

Below is a full example:

Dockerfile

FROM nginx:alpine
ARG KEY1
ARG KEY2

RUN echo "$KEY1" && echo "$KEY2"

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: tilt
  labels:
    app: tilt
spec:
  replicas: 1
  selector:
    matchLabels:
      app: tilt
  template:
    metadata:
      labels:
        app: tilt
    spec:
      containers:
      - name: tilt
        image: tilt:test
        ports:
        - containerPort: 80

Tiltfile

k8s_yaml('deployment.yaml')

docker_build('tilt', '.', {'KEY1': 'key1', 'KEY2': 'key2'})

Tilt output

──┤ Building: tilt ├──────────────────────────────────────────────                                             ↑
STEP 1/2 — Building Dockerfile: [docker.io/library/tilt]
  │ Tarring context…
    ╎ Created tarball (size: 4.6 kB)
  │ Building image
    ╎ [1/2] FROM docker.io/library/nginx:alpine
    ╎ [2/2] RUN echo "key2" && echo "key2"

Note that both keys are set to key2

Docker output

$ docker build --build-arg KEY1=key1 --build-arg KEY2=key2 -t tilt:test .           1 ↵
[+] Building 1.1s (6/6) FINISHED
 => [internal] load .dockerignore                                                                          0.0s
 => => transferring context: 2B                                                                            0.0s
 => [internal] load build definition from Dockerfile                                                       0.0s
 => => transferring dockerfile: 113B                                                                       0.0s
 => [internal] load metadata for docker.io/library/nginx:alpine                                            0.0s
 => CACHED [1/2] FROM docker.io/library/nginx:alpine                                                       0.0s
 => [2/2] RUN echo "key1" && echo "key2"                                                                   1.0s