tilt-dev / tilt-dev/tilt

reconnect to existing services

Open
#3,961 0 comments 0 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

When people are using a remote cluster, a pattern we've seen is that they don't WANT to restart all the services from scratch. They want Tilt to check if the server is already there, and if possible, try to reconcile with what they had locally.

In other cases, they'd be fine with Tilt reconnecting to a stale version of a service, and updating that service to the fresh version in the background (rather than blocking other builds on it).

We've had trouble making progress on it because the product experience is deeply tied to the technical implementation, and there's a couple different ways you can solve it, between:

  • More robust caching of image builds - https://github.com/tilt-dev/tilt/issues/3690
  • A "live connect" feature that checks if the binary can be made consistent with the local workspace with live-update sync alone
  • A way to deliberately use a pre-built image when available
  • A way to share images across teams (https://github.com/tilt-dev/tilt/issues/3629)
  • Changing the ergonomics about updating on the first tilt up, so that Tilt will only do the initial build if you confirm that that you want to replace the existing one.

I think the sheer number of options here speaks to how painful it is for app devs to start Tilt once you have more than a handful of services, and different ways that people are willing to sacrifice correctness to speed it up.

Filing this issue just to collect thoughts and feedback on this and what the right trade-offs are here between possible solutions

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

No files, tests, or entry points are identified. Start by reviewing the referenced caching and image-sharing issues, then compare the listed reconnect, live-connect, pre-built-image, and first-run update options; done would require a decided product direction and defined implementation scope.

Written by the indexing model from the issue text.

Assessment

Tech stack
kubernetes
Domain
infrastructure
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.