Gerrit Code Review - Building with Bazel

To build Gerrit from source, you need:

Debugging tests:

Debug test example:

To run a specific test group, e.g. the rest-account test group:

To run only tests that do not use SSH:

To exclude tests that have been marked as flaky:

To exclude tests that require a Docker host:

To ignore cached test results:

To run one or more specific groups of tests:

The following values are currently supported for the group name:

Dependency JARs are normally downloaded as needed, but you can download everything upfront. This is useful to enable subsequent builds to run without network access:

When downloading from behind a proxy (which is common in some corporate environments), it might be necessary to explicitly specify the proxy that is then used by curl:

Redirection to local mirrors of Maven Central and the Gerrit storage bucket is supported by defining specific properties in local.properties, a file that is not tracked by Git:

The local.properties file may be placed in the root of the gerrit repository being built, or in ~/.gerritcodereview/. The file in the root of the gerrit repository has precedence.

To build against unpublished Maven JARs, like gwtorm or PrologCafe, the custom JARs must be installed in the local Maven repository (mvn clean install) and maven_jar() must be updated to point to the MAVEN_LOCAL Maven repository for that artifact:

To build against custom Maven repositories, two modes of operations are supported: with rewrite in local.properties and without.

Without rewrite the URL of custom Maven repository can be directly passed to the maven_jar() function:

When the custom URL has to be rewritten, then the same logic as with Gerrit known Maven repository is used: Repo name must be defined that matches an entry in local.properties file:

And corresponding WORKSPACE excerpt:

To consume the JGit dependency from the development tree, edit lib/jgit/jgit.bzl setting LOCAL_JGIT_REPO to a directory holding a JGit repository.

To accelerate builds, several caches are activated per default:

Currently none of these caches have a maximum size limit. See this bazel issue for details. Users should watch the cache sizes and clean them manually if necessary.

Parts of the PolyGerrit build require running NPM-based JavaScript programs as "binaries". We don’t attempt to resolve and download NPM dependencies at build time, but instead use pre-built bundles of the NPM binary along with all its dependencies. Some packages on registry.npmjs.org come with their dependencies bundled, but this is the exception rather than the rule. More commonly, to add a new binary to this list, you will need to bundle the binary yourself.

Start by checking that the license and file types of the bundle are acceptable:

This will output a list of the different licenses used by the package and all its transitive dependencies. We can only legally distribute a bundle via our storage bucket if the licenses allow us to do so. As long as all of the listed license are allowed by Google’s standards. Any by_exception_only, commercial, prohibited, or unlisted licenses are not allowed; otherwise, it is ok to distribute the source. If in doubt, contact a maintainer who is a Googler.

Next, check the file types:

If you see anything that looks like a native library or binary, then we can’t use the bundle.

If everything looks good, create the bundle, and note the SHA-1:

This creates a file named $package-$version.tgz in your working directory.

Any project maintainer can upload this file to the storage bucket.

Finally, add the new binary to the build process:

To use the binary from the Bazel build, you need to use the run_npm_binary.py wrapper script. For an example, see the use of crisper in tools/bzl/js.bzl.

The Bazel build can be used with Google’s Remote Build Execution.

This needs the following setup steps:

Create a worker pool. The instances should have at least 4 CPUs each for adequate performance.

To use RBE, execute

Part of Gerrit Code Review