When doing continuous integration, you do not want your build to fail because a a tool invoked during the build has been updated or some environmental conditions have changed. Because Bazel is designed for reproducible builds and keeps track of almost every dependency of your project, Bazel is a great tool for use inside a CI system. Bazel also caches results of previous build, including test results and will not re-run unchanged tests, speeding up each build.
Bazel runs most build actions as a separate process. Many build actions invoke a compiler. However, starting a compiler is often slow: they have to perform some initialization when they start up, read the standard library, header files, low-level libraries, and so on. That’s why some compilers and tools have a persistent mode, e.g. sjavac, Nailgun and gcc server. Keeping a single process for longer and passing multiple individual requests to the same server can significantly reduce the amount of duplicate work and cut down on compile times.
This post was updated on 2017-12-19 to remove outdated information that caused frequent misunderstanding of Bazel's sandboxing feature.
Reposted from Google's Open Source blog.
WARNING: This feature has been removed (2017-04-19).
Docker images are great to automate your deployment environment. By composing base images, you can create an (almost) reproducible environment and, using an appropriate cloud service, easily deploy those image. However, V1 Docker build suffers several issues:
Reposted from @kchodorow's blog.
Let say that you want to build for Java 8 and errorprone checks off but keep the tools directory provided with Bazel in the package path, you could do that by having the following rc file:
You can customize the options Bazel runs with in your ~/.bazelrc, but that doesn't scale when you share your workspace with others.
We recently open-sourced our support for Error Prone. Error Prone checks for common mistakes in Java code that will not be caught by the compiler.