Express dependency of one resource on the latest version of another resource

[boyd-bit-io]

I would like a way to say "'foo' depends on 'bar'. If 'bar' changes, reload 'foo' with the most recent and up-to-date version of bar".

For example, in my team's Tiltfile, we have a local_resource which runs unit tests for our main webapp. I've set a dependency in the testing local resource on the webapp, i.e. local_resource('run_tests', cmd='./run_tests.sh', ..., resource_deps=['core-webapp']). In practice, I've found that updating core-webapp triggers a test run, but usually the test run is against an out of date version of the webapp. This makes it appear that a test is still broken, even if the most recent change fixes it, and makes it look like tests are fine, even when the most recent change broke things. Usually, manually running tests a second time shows correct results.

https://docs.tilt.dev/resource_dependencies.html says "This feature currently mostly only helps in the common case that different versions of services are broadly compatible with each other, and focuses on ensuring that some instance of a resource’s dependencies exist, without worrying too much about whether it’s a current version. For this reason, resource_deps currently only affects the first build after a tilt up. e.g., Once any version of database has been running at least once, its dependencies are unblocked to build for the rest of Tilt’s lifetime."

We would like to depend on the current version, please!

[boyd-bit-io]

@adamf ^

[nicks]

thanks for the request! ya, the "auto-run tests when the service update" use-case has come up a couple times recently in different forms. Agreed that resource_deps is not good for this.

[wu-victor]

@boyd-bit-io : We are exploring how to make tests a first class citizen in Tilt. So you would define them with a dedicated function in your Tiltfile (instead of using local_resource). And you would see them in a separate place in the web UI (instead of in the resources sidebar).

Is this something that would be interesting to you?

[adamf]

@victorwuky we would love this!

[grzegorznowak]

@boyd-bit-io : We are exploring how to make tests a first class citizen in Tilt. So you would define them with a dedicated function in your Tiltfile (instead of using local_resource). And you would see them in a separate place in the web UI (instead of in the resources sidebar).

for us the resource sidebar is not an issue, and frankly I do like the flexibility labeling can offer, where you could easily put related services into their own silos with their relevant tests.

Where I think tilt is currently indeed a bit lacking is the local_resources' capabilities to talk with each other and (re-)trigger each other via dependencies.

To give you some real example based on the simplified containerized TDD app we've setup a

local_resource('stub-camunda-engine')

to serve as the stub backend for

local_resource('processes-integration-tests',
trigger_mode=TRIGGER_MODE_MANUAL)

note the manual trigger flag ^, which, to save resources, is so that devs can issue integration tests only when they are ready to do so. It won't however work ootb without a few hacks along the way as what we also need to be doing is respinning the stub-camunda-engine container to the pristine state right before tests can be ran.

We're getting deep deep into Tilt so hope to speak with you more and more. Having a load of projects of varied sizes being currently tiltized, so can provide some, hopefully, interesting cases for days.

[matdurand]

Any progress on this? I agree that tests as first class citizen would be nice, but we could get away with expressing update dependencies to retrigger something after a dependency is updated.

I don't mind giving it a shot, but I'm new to Tilt and Starlark so I would need guidance on how we could achieve this. It might be a bit too big for a first contribution though ...