This makes it hard to tell at a glance which targets had to get rebuilt in a given test invocation without examining the profile. I believe this happens because the test creates an intermediate target as input to the no-op test. Since that target is the same regardless of srcs, the test rule itself detects that its inputs didn't change, and thus shows "cached".
One sample usage of build_test is to make sure a typescript typechecking target is up-to-date. The RBE size concerns don't apply there, because any typescript library using this target as a dependency already needs to be able to load all the output typings that are being verified by build_test.
I had a few possible ideas for improving this:
1) Output a random number or the current timestamp or something similar to the intermediate targets to force the test to run when inputs change
2) A more-deterministic option is to hash all the inputs together but that might have perf implications
3) Remove the batching behavior and associated intermediate outputs
4) Make the batch size configurable and avoid batching if the number of files is small enough to fit in a single batch. Typescript rules can set the batch size to the number of outputs to effectively disable the batching.
alexeagle
commented
10 months ago
This makes it hard to tell at a glance which targets had to get rebuilt in a given test invocation without examining the profile. I believe this happens because the test creates an intermediate target as input to the no-op test. Since that target is the same regardless of srcs, the test rule itself detects that its inputs didn't change, and thus shows "cached".
One sample usage of
build_testis to make sure a typescript typechecking target is up-to-date. The RBE size concerns don't apply there, because any typescript library using this target as a dependency already needs to be able to load all the output typings that are being verified bybuild_test.I had a few possible ideas for improving this: 1) Output a random number or the current timestamp or something similar to the intermediate targets to force the test to run when inputs change 2) A more-deterministic option is to hash all the inputs together but that might have perf implications 3) Remove the batching behavior and associated intermediate outputs 4) Make the batch size configurable and avoid batching if the number of files is small enough to fit in a single batch. Typescript rules can set the batch size to the number of outputs to effectively disable the batching.
Thoughts?