tilt-dev / tilt-dev/tilt

Integrating `git pull`/`git clone` with Tilt

Open
#3,663 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

Disclaimer: this issue discusses a good motivating example, but a better name for the issue should be found

The Problem

In the Git Resource Extension a git fetch is performed in a local each time the Tiltfile executes to ensure that the most recent version is checked out. This has two downsides:

  1. It's slow. If you have a lot of git_resources in your Tiltfile it can be costly to do a git fetch on all of them in serial
  2. It can't be triggered without a full re-execution of the Tiltfile (at least until #3662 is resolved)

It would be better, and feels natural, to make that git fetch a local_resource. However, if you do that you run in to a problem if you wanted to pass any of the files that are in the git_resource to k8s_yaml. Imagine this Tiltfile:

local_resource('git pull', 'git pull https://github.com/paulbouwer/hello-kubernetes.git', trigger_mode=TRIGGER_MODE_MANUAL, auto_init=True)
k8s_yaml('hello-kubernetes/yaml/hello-kubernetes.yaml')

If you run this Tiltfile it complains that hello-yaml doesn't exist.

This makes sense because Tilt, like many build tools, does a two step process. The Tiltfile executes to tell the engine what to do, and then the engine does what is necessary. In this case k8s_yaml expects the file to exist, but it hasn't been created yet because we're still in step 1 and step 2 (the engine) hasn't run the local resource yet.

Potential Solutions

I'm not sure if any of these actually work, but here's what I discussed with @nicks earlier:

  1. A new parameter to k8s_resource called generate_yaml. This takes a python lambda which is responsible for generating the YAML that will be associated with the k8s_resource. It can do whatever it needs to do to generate that YAML. Then when the engine builds this resource generating the YAML will be just another build step.
  2. Here's something @KOGI put together in k8s slack:
def my_callback(completed_resources=[]):
    do_something('foo', 'bar')
resource_name = local_resource('whatever', 'some command')
await_resources(resource_deps=[resource_name], my_callback)

Next steps

What other ideas are there? What are the pros/cons of these different approaches?

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 with the Git Resource Extension and its Tiltfile git fetch call, then trace how local_resource, k8s_yaml, and k8s_resource are evaluated. Compare the proposed generate_yaml and await_resources approaches, including the interaction with #3662. Done means a concrete design is selected with its trade-offs documented.

Written by the indexing model from the issue text.

Assessment

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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.