
Continuous Integration and Deployment with Bazel - chmaynard
https://blogs.dropbox.com/tech/2019/12/continuous-integration-and-deployment-with-bazel/
======
new_realist
> We modified our continuous integration system to extract this dependency
> information from Bazel (via bazel query) and use it to compute the set of
> tests affected by a particular commit. This allows us to greatly reduce the
> number of tests executed on most commits while still being correct.

Why didn’t they just rely on Bazel’s built in test caching? It does the same
thing.

~~~
Game_Ender
Basel’s built in caching requires you build the test (even with cached this
takes a bit to love the bites) then you can figure out your already have the
result.

You save a large amount of time if you can tell Bazel only to evaluate the
part of the tree you know a change effects.

~~~
new_realist
Bazel will cache already built tests as well, and only rebuild those which
have changed. Are you saying that it’s cheaper to evaluate Bazel’s dep. graph
yourself rather than have Bazel do it? Bazel caches the dep. graph too. Have
you tried —-watchfs? Don’t tear down the daemon needlessly, either.

