Hacker News Reader

> 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.

View on HN

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.

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.

Reply on news.ycombinator.com