| commit | 4443123db935fafd6f51f9c1f03bba1bc6538a22 | [log] [tgz] |
|---|---|---|
| author | Kush Chakraborty <kush@google.com> | Thu Mar 23 22:51:54 2017 +0000 |
| committer | Yue Gan <yueg@google.com> | Fri Mar 24 12:19:19 2017 +0000 |
| tree | 4a6b193856f1917a3195f2f189acc9e904d07180 | |
| parent | ea862bac70646d519388955a71d6189a0f01459e [diff] |
2nd attempt to split classpaths, and load test classes in a separate classloader. Currently this funcionality is hidden behind the "experimental_testrunner" flag. Original description (from commit 786cfa2ed980e278c42ee474408844f7e3720385): Separate the classpaths of the TestRunner with the test target, and use a separate Classloader to load the test target's classes. This enables a clean separation of the classes of the TestRunner with the target under test. This is achieved with the following steps: 1. Start the test runner with only the bare bones classpaths to the Test Runner's classes which are used by the system ClassLoader. 2. Have all the classpaths required to load the test target's classes in a TEST_TARGET_CLASSPATH environment variable exported by the stub script. 3. Use a new classloader to load all the test target's classes using the paths in TEST_TARGET_CLASSPATH. This additionally enables the persistent test runner (currently experimental), to reload all the target's classes for every subsequent test run, so it can pick up any changes to the classes in between runs. The persistent test runner can be used by adding the argument --test_strategy=experimental_worker to the bazel test command (and having the tag "experimental_testrunner" in the java_test rule). Tested this against: 1. gerrit/gerrit-common:client_tests: Dismal avg. improvement of 580ms to 557ms (just 23ms) 2. intellij/intellij/base:unit_tests: Somewhat modest avg. improvement 1661ms to 913ms (748 ms) -- PiperOrigin-RevId: 151065529 MOS_MIGRATED_REVID=151065529
{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.