no way to express build dependencies in Tilt

[nicks]

Currently, Tilt has resource_deps for expressing runtime initialization dependencies (e.g., "You need to start up the database before the frontend").

But Tilt has no way to express other types of dependencies, including:

1. A common pattern is to have a local_resource that generates files, and then a docker_build that syncs those files to a container. (e.g., generating API documentation in tilt.build, compiling Go static binaries). This workflow has a bunch of rough edges (logs aren't grouped like you would expect them, redundant builds, etc)

2. Another common pattern is to have a local_resource that solely exists to kick off another build (e.g., the "touch Tiltfile" script described in support manually triggering tiltfile executions #2957, or the "measure deployment" script described in https://docs.tilt.dev/example_static_html.html). These scripts are prone to race conditions and infinite loop problems (local that generates yaml causes infinite loop #1930)

People often try to do this with resource_deps, and are confused about why it doesn't work. See also discussion on this PR: #2837 (comment)

I don't know what the solution is to this problem, or even if (1) or (2) are the same problem. This issue is just to have a place to point people who ask about this while we think about what to do about it.

[jmo-qap]

To bring some more commentary to the issue, it is is hitting us pretty hard in terms of development work hours and development speed slowness.

1. We have tests we want to run after a certain service is updated. We have to run the whole test suite twice (the second time triggered manually) to get a true result. Described in Express dependency of one resource on the latest version of another resource #3667

2. We have the following steps that must happen in the following order (otherwise several services in the cluster will enter an error state and create crash loops): (a) database migration file generation, (b) execute database migration files, (c) restart/update service. For (a), we've moved it into a separate docker build stage which works but only without live update. Doing (a) locally as a separate command causes a double sync and will put the cluster into an error state first. For (b), we've added etcd as a lock service and the first service to start aquires the lock and does (b) while all the other services spin on the lock. Then, (c) can progress. The alternative is to configure all those services to update only on manual trigger and manually trigger in the right order. That is also slow because manual trigger removes the ability to live_update (unless I'm missing how the feature works).

Finally, pointing to the other issue on the topic to bring it all into one place:
#3676
#3319

[nicks]

@jmo-qap thanks for the context!

ya, just to make sure it's clearly stated, manual trigger should still work with live_update.

one idea i've been thinking of is taking the Unix philosophy of "Everything is a File" and running with it -- make it so that in Tilt, "everything is a file watch". You can do this today without any special features! e.g., have special local_resource(serve_cmds) that wait for X to happen, then write file Y, and have other things (tests, etc) trigger on changes to file Y.

It's a little bit rube-goldbergy right now, but we see other teams do it. i think we could add primitives that make it easier, but this might be a strategy to unblock you.

[Raboo]

My use case is that I would to execute a command after docker_build() or custom_build(). Simply put a post_build() resource.

[CpuID]

My use case here is I would like to run git pull via local() on a directory before executing docker_build(), to pull in the latest code from various active development systems that rapidly change.

I originally considered using git_resource but for some reason it's not updating my Helm chart Docker image ref (in the pod spec), it doesn't change the tag/version for whatever reason - unrelated issue...

[mvgijssel]

I've implemented a basic post_build Tilt extension like this

def post_build(name, resource, cmd):
    local_resource(
        name,
        serve_cmd="""
        #!/usr/bin/env bash
        set -Eeou pipefail

        echo "Starting post build"

        while :
        do
            # timeout -1s means a week
            tilt wait --timeout=-1s --for=condition=UpToDate=true uiresource/{resource}

            echo "Build UpToDate! Running post_build command"

            {cmd}

            tilt wait --timeout=-1s --for=condition=UpToDate=false uiresource/{resource}
            echo "Build not UpToDate..."
        done
        """.format(resource=resource, cmd=cmd),
    )

Which allows me to run arbitrary commands after a docker image updates . In this particular example I'm running a command to skip the onboarding step of home assistant after the container is reachable.

post_build(
    "skip_onboarding",
    resource="home-assistant",
    cmd="""
    docker compose exec home-assistant wait-for -t 0 localhost:8123

    curl --location --request POST 'http://127.0.0.1:8123/api/onboarding/users' \
    --header 'Content-Type: application/json' \
    --data-raw '{
        "client_id": "http://127.0.0.1:8123/",
        "name": "admin",
        "username": "admin",
        "password": "admin",
        "language": "en"
    }'
    """,
)

[Raboo]

@mvgijssel Would you perhaps make a Tilt extension from this?

[bcsgh]

Any further progress on this? The point I'm tripping over is that, as best I can tell, my docker_build() is attempting to build before all it's inputs are generated and for "reason" this results in having to manual re-trigger things.

Grossly over simplified, the first image ends up "sticky" down the line and the invalidation when the rest of the files shows up doesn't lead to a correct result. The "correct fix" is to make things so that the invalidation works, but that "gets complicated" so it's not happening soon and it would be better all around (even after things are fixed on my end) to just not run the docker_build() when we know the files it needs aren't ready yet.