`tilt up` without rebuilding container image

[rodrigoscna]

Describe the Feature You Want

There could be a way to tilt up (with a flag or maybe an environment variable) that runs everything as it would, but without ever rebuilding the container images. This would be useful for applications like Node.js that can reload based on file changes without the need to rebuild the whole container image.

Current Behavior

As it is now, tilt up will always build the docker images.

Why Do You Want This?

It would be useful specially for large monorepo applications where you can have your applications handle file changes without the need for a new container image to be rebuilt.

I am aware of the file_sync_only extension, but it requires some complex logic to be used with something like helm_resource (like rendering templates of the manifests to use in file_sync_only).

The proposal is something that does not requires any changes on the existing Tiltfiles, but rather just connect to existing deployed resources.

I'm not sure if it is even possible, since Tilt generates the image tag at the moment of the command, but maybe persisting the last used tag, or even connecting based solely on the image repository, without a tag.

[lizzthabet]

thanks for the feature request @rodrigoscna! tilt computes a content-based tag for each image, so as long as that doesn't change, tilt shouldn't be doing full rebuilds (even on tilt up). generally we see folks use image layer caching to minimize build time, but that may not have the impact you need in a large monorepo!

have you seen the tiltfile config docs? there's an example of defining a custom argument to tilt (in this case, it's called to-edit) and using the input to determine which docker_build calls to make. i wonder if that might get closer to the behavior you're looking for.

if you'd like to use the file_sync_only extension, you may also be able to use the helm built-in to grab a chart's yaml.

[rodrigoscna]

Thanks for the response @lizzthabet I'm actually already using image layer caching in my deployments, but it's not enough.

The thing is, I have tens of microservices being redeployed when I run tilt up and it takes a while for all of them to be ready. And I would like for all of them to be "editable" without me having to re-run a to-edit command when I'm switching contexts.

But if Tilt was able to only connect to them and sync files from this moment on, it would basically be instantaneous.

I'm aware of the file_sync_only and the helm built-in. But they would demand some logic to be implemented on the Tiltfiles. I'll give those a try, but it would be great if Tilt could have this feature built-in.

[nicks]

this discussion might be relevant: https://github.com/tilt-dev/tilt/issues/3282

i might quibble a bit with the statement "But if Tilt was able to only connect to them and sync files from this moment on, it would basically be instantaneous." An ad hoc filesync initialization step - making sure to both add new files and delete old ones - might not be instantaneous, and might even be slower than building a fresh immutable image. there's more back-and-forth communication, more edge cases, and fewer opportunities for caching.

But I appreciate your complaint that if you have tens of microservices, tilt up is still too slow.

[rodrigoscna]

I don't think it would be necessary to re-sync everything at the moment you start Tilt, only new changes/removals made after you start Tilt would be synced.

In any way, I was just making a feature suggestion. Didn't mean to complain or anything. Actually love using Tilt.

[grzegorznowak]

hey @rodrigoscna , just stumbled upon this and thought I'd hook into with a related use-case question.

We're currently mid rewriting apps into k8s with the help of tilt and that what you described is one of the first problems that got me thinking on how to wrap the devops around.

We concluded that the best initial setup is going to be:

tilt ci in a master provisioning repo to bootstrap the whole service's landscape and have stuff talking with each other, and then tilt up in specific project that dev is working on. So that the heavy weight is done once and only minimal top-up build is required for all the live_sync goodies.

Based on your experience so far, would that work in long run or we're missing the target completely ?

[rodrigoscna]

Hello @grzegorznowak, I believe that strategy will help us for now, thank's for the suggestion.