gerrit_plugin: Improve stamping error message

Bazel stamp error message is very misleading and hard to track down
and understand. A number of prerequisites must be met for the stamping
machinery to work properly.

Bazel's missing feature to dynamically construct MANIFEST.MF file and
pass such file to java_binary rule contributes to this problem: [1].

To rectify, split the stamp information retrieval in its own rule. The
reason for the failure is because bazel is using "set -o pipefail" for
genrules. This particular option sets the exit code of a pipeline to
that of the rightmost command to exit with a non-zero status, or to
zero if all commands of the pipeline exit successfully.

Given the self descriptive rule name: <plugin>__gen_stamp_info it is
clear where to look for, in tools/workspace-status.sh command.

Test Plan:

1. Apply this CL in bazlets repository
2. Clone reviewers plugin and switch to consume bazlets from local
directory
3. Patch tools/workspace-status.sh file and replace this line:
echo STABLE_BUILD_REVIEWERS_LABEL $(rev .)
with:
echo STABLE_BUILD_REVIEW_LABEL $(rev .)
4. Run bazel build :reviewers and notice that correct failing rule is
now reported:

  $ bazel build reviewers
  INFO: Analysed target //:reviewers (0 packages loaded).
  INFO: Found 1 target...
  ERROR: /home/davido/projects/reviewers/BUILD:3:1: Executing genrule //:reviewers__gen_stamp_info failed (Exit 1)
  Target //:reviewers failed to build

[1] https://github.com/bazelbuild/bazel/issues/2009

Change-Id: Ia2ad7238f77cafb89fa822b78c5d658ccedc8d11
(cherry picked from commit 4459b9706a6eedb8453a98d4434fb3bc4db84211)
1 file changed
tree: 3dbba334fb7400e5bae1d71239c7f8fb7d4ab67d
  1. lib/
  2. tools/
  3. .gitignore
  4. bouncycastle.bzl
  5. BUILD
  6. COPYING
  7. gerrit_api.bzl
  8. gerrit_api_maven_local.bzl
  9. gerrit_gwt.bzl
  10. gerrit_plugin.bzl
  11. README.md
  12. WORKSPACE
README.md

Gerrit Code Review Rules for Bazel

Overview

These build rules are used for building Gerrit Code Review plugins with Bazel. Plugins are compiled as .jar files containing plugin code and dependencies.

Setup

To be able to use the Gerrit rules, you must provide bindings for the plugin API jars. The easiest way to do so is to add the following to your WORKSPACE file, which will give you default versions for Gerrit plugin API.

git_repository(
  name = "com_github_davido_bazlets",
  remote = "https://github.com/davido/bazlets.git",
  commit = "2ede19cb2d2dd9d04bcb70ffc896439a27e5d50d",
)
load("@com_github_davido_bazlets//:gerrit_api.bzl",
     "gerrit_api")

Another option is to consume snapshot version of gerrit plugin API from local Maven repository (~/.m2). To use the snapshot version special method is provided:

load("@com_googlesource_gerrit_bazlets//:gerrit_api_maven_local.bzl",
     "gerrit_api_maven_local")
gerrit_api_maven_local()

Basic Example

Suppose you have the following directory structure for a simple plugin:

[workspace]/
    WORKSPACE
	BUILD
    src/main/java/
	src/main/resources/
	[...]

To build this plugin, your BUILD can look like this:

load("//tools/bzl:plugin.bzl", "gerrit_plugin")

gerrit_plugin(
    name = "reviewers",
    srcs = glob(["src/main/java/**/*.java"]),
    gwt_module = "com.googlesource.gerrit.plugins.reviewers.ReviewersForm",
    manifest_entries = [
        "Gerrit-PluginName: reviewers",
        "Gerrit-Module: com.googlesource.gerrit.plugins.reviewers.Module",
    ],
    resources = glob(["src/main/**/*"]),
)

Now, you can build the Gerrit plugin by running bazel build <plugin>.

For a real world example, see the reviewers plugin.

gerrit_plugin

gerrit_plugin(name, srcs, resources, gwt_module, deps, manifest_entries):

Implicit output target

  • <name>.jar: library containing built plugin jar