Make it clear when Tilt is reattaching to an existing k8s resource
Nobody has claimed this yet.
- 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:
- the docker build is entirely cached
- the image already exists in the registry
- 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
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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