Tilt: (optionally) tear down resources on Tilt exit

[maiamcc]

Many users like the fact that exiting Tilt leaves all your old resources up--your next Tilt run can hook into pods from last time (if nothing has changed) and speed up your startup time.

However, for users who want Tilt to tear down resources on exit (as e.g. Docker Compose does), this should be an option. (tilt up --teardown=true? teardown(true) in Tiltfile?)

[kvokka]

I like the idea, but maybe we can adopt Docker flag --rm here?

in Tilefile it would be reasonable to introduce some settings or defaults command, where user can overlap it with rm=true. This should be an answer for further Tilt configuration switches.

thoughts?

[maiamcc]

Yeah, we're already thinking of ways for long-lived configurations to interact with command line flags (so, e.g., you could EITHER set --rm as a default somewhere in a config file, OR if you only use it infrequently, pass it as an arg to tilt up whenever you need it).

Cool, thanks for all your input! This feature isn't going to be implemented in the immediate future, but a few people have mentioned it already, so it's good to have a central ticket for it. Watch this space for any news, and let us know if your use case changes/if this feature gets any more significant for you.

[stecky]

+1 for this enhancement. I do local development on my laptop, but it's nice to have an easy way to shut everything down when I'm not using it. Especially if I am running on battery.

[nickvollmar]

Nowadays I run Tilt as tilt up && tilt down, which achieves automated teardown behavior (at the cost of reading the Tiltfile twice).

[tmc]

FWIW I like the in-tiltfile option here as i think it's the most flexible

[kevin-lindsay-1]

IMO it would be nice to have an in-tiltfile approach for this, but in general I think that the CLI invocation itself should be respected "above all", because the user is manually stating it, but that leads into which is more authoritative, a hard-coded value in Tiltfile, or the user on the CLI.

You could say cleanup/remove/teardown: true in tilt_config.json, create a globally scoped function like teardown(true), but the manual process of providing a flag on the CLI would IMO be the determining factor, because I actually wrote it. That way, I can say "teardown by default, sure, but in this case don't".

---

To piggyback off the previous paragraph, it brings up a question that I think may continually be asked, that being "what are the options for config (outside of custom stuff), and what is the order in which they override?".

In my mind, the order of override would be as follows:

• Declarative config (a la tilt_config.json) (least respected)
• CLI arguments
• Hard-coded Tiltfile (most respected)

The issue of best practices comes into play when having an option such as teardown in all 3 contexts, leading to the ability to erroneously hard-code teardown(true) in Tiltfile, ignoring both config and CLI arguments.

[daniel-kun]

I second @kevin-lindsay-1 's approach of having the three-tier config options (which must be very properly documented!). I know it from other tools and have had a good experience with it so far.

Personally I would think that when you like the tear-down-behaviour, it must not be the case that all your teammates like it, so a user-config would be a better approach to have this be the default behaviour.

However, when you want to apply it as some kind of "policy" for your whole team, the Tiltfile would be a better approach.

Lastly, there surely are unregular cases where you want a different behaviour than that what is configured in your personal config or the Tiltfile.

That's why I would re-order the priority to

• User config (least respected)
• Tiltfile (overwrites user config)
• CLI arguments (overwrites Tiltfile and user config)

Greetings!
Daniel