| commit | fa389066641ac7f92b220ef232f23e757704318d | [log] [tgz] |
|---|---|---|
| author | Luis Fernando Pino Duque <lpino@google.com> | Tue Oct 18 14:28:42 2016 +0000 |
| committer | Philipp Wollermann <philwo@google.com> | Wed Oct 19 08:26:02 2016 +0000 |
| tree | cfedd733426e8b7b95b87105bd6344a6c0154983 | |
| parent | aecf826aa0cd12d25a8f6d69604d721f50d940f0 [diff] |
Create a proper wrapper script for executing "bazel" in the integration tests. Currently a call to "bazel" in an integration test means calling a (quite hidden) function in test-setup.sh which actually calls "$bazel" defined in "shell/bazel/testenv.sh" which is equal to "$(rlocation io_bazel/src/bazel)". This is extremely confusing and error prone. The new mechanism is to add a wrapper script to shell/bin called bazel and export this directory to the PATH. Moreover, not every test loads the same test environment, for instance consider how bazel_query_test loads the test environment: - Load shell/integration/testenv.sh which loads, - shell/bazel/test-setup.sh which loads, - shell/bazel/testenv.sh which loads, - shell/unittest.bash which loads, - shell/testenv.sh Again this is error prone and specially hard to understand, in fact each test writer needs to decide which of these testenv to load. This change fixes all of this by having only one testenv.sh and summarizing the test setup in integration_test_setup.sh. Namely, for any new integration test, the developer needs to load integration_test_setup to get the environment set up including the unittest framework (also it helps to attract contributions). This change also allows to open sourcing client_sigint_test: Since bazel was a function client_sigint_test was using a wrong process id to interrupt the build. The problem is that $! returns bash's id instead of the id of the process running in the background when using a function instead of an executable. A few tests needed to be adapted to the new infrastructure. -- MOS_MIGRATED_REVID=136470360
{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.