tilt-dev / tilt-dev/tilt

Make it clear when Tilt is reattaching to an existing k8s resource

Open
#5,353 1 comment 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
Go
Stars
10.1k
Forks
413
Avg merge
1d 10h
Merged PRs (30d)
6

Description

Describe the Feature You Want

When building a k8s resource, it is possible that nothing has changed since the last deployment, and:

  1. the docker build is entirely cached
  2. the image already exists in the registry
  3. the injected k8s yaml matches the k8s yaml in the cluster, so the apply is a noop

In this case, the build is generally extremely fast, and doesn't restart any pods that might be running as part of the k8s resource.

This request is to make clear to the user when this happens.

(this might be multiple related changes, for #s 1, 2, 3 above)

Current Behavior

Tilt logs the build + push + deploy, and the output looks mostly the same as any other build + push + deploy. AFAIK, the main observable difference is that all the build steps have [cached].
When repro'ing this, even as a Tilt dev, I found it hard to confirm the behavior without going outside of Tilt.

Why Do You Want This?

A number of users have requested behavior that already exists, but isn't visible.

It's possible actual use cases for being aware of this are slim, and this is a low-impact feature. The main benefit I can think of is that better awareness of when Tilt will do more or less work will allow users to make better decisions about what kinds of changes they make (e.g., "maybe I won't merge master just yet since that'll force a redeploy"). More concrete reasons in the replies are welcome!

It's also possible that something simple like logging "re-using existing k8s object ✅" when the uid doesn't change on apply would give users more confidence Tilt is doing good things for them. (or maybe that isn't that simple on the initial tilt up)

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing Tilt's Kubernetes build, push, and deploy output for the three cases described: cached builds, existing registry images, and no-op applies. Determine where each case can be distinguished and define user-visible messaging that makes reattachment clear without implying a restart; done when users can confirm this behavior from Tilt alone.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, go, kubernetes
Domain
devops, infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.