| commit | f812a2f8dfebf21645cbb559a29357b627edddde | [log] [tgz] |
|---|---|---|
| author | Googler <noreply@google.com> | Mon Jun 13 16:14:10 2016 +0000 |
| committer | Yue Gan <yueg@google.com> | Tue Jun 14 08:14:27 2016 +0000 |
| tree | a5cc943a2b94498f9ed8a216beaf9e966232dd2c | |
| parent | 5160d196e62bf6f8fa56b32746a01b182729c5c8 [diff] |
Add --[no]instrument_test_targets option to Blaze When true (the default), test rules included by --instrumentation_filter are instrumented. When false, test rules are excluded from instrumentation (whether or not their names would be matched by --instrumentation_filter). This option provides a superior way to exclude test rules from instrumentation, compared to setting --instrumentation_filter exclusions based on test rule naming conventions. Naming conventions vary from language to language and are not always followed. Blaze already has enforced semantics for test targets (test rule build function names _must_ end in "_test", see TargetUtils.isTestRule). In general, when either option is available, it's better to rely on enforced semantics than unenforced conventions. Note that this default preserves present behavior. In the future, I think it would make sense to: * Change the default value of --instrument_test_targets to false. * Change the default value of --instrumentation_filter to an empty string (match everything). RELNOTES: Add --instrument_test_targets option. -- MOS_MIGRATED_REVID=124732226
{Fast, Correct} - Choose two
Bazel is a build tool that builds code quickly and reliably. It is used to build the majority of Google‘s software, and thus it has been designed to handle build problems present in Google’s development environment, including:
A massive, shared code repository, in which all software is built from source. Bazel has been built for speed, using both caching and parallelism to achieve this. Bazel is critical to Google's ability to continue to scale its software development practices as the company grows.
An emphasis on automated testing and releases. Bazel has been built for correctness and reproducibility, meaning that a build performed on a continuous build machine or in a release pipeline will generate bitwise-identical outputs to those generated on a developer's machine.
Language and platform diversity. Bazel's architecture is general enough to support many different programming languages within Google, and can be used to build both client and server software targeting multiple architectures from the same underlying codebase.
Find more background about Bazel in our FAQ.