commit | 315103d634a651295d180ce1381be94b51bb9062 | [log] [tgz] |
---|---|---|
author | David Ostrovsky <david@ostrovsky.org> | Tue May 15 21:42:54 2018 +0200 |
committer | David Ostrovsky <david.ostrovsky@gmail.com> | Tue Jun 12 21:34:35 2018 +0000 |
tree | 3dbba334fb7400e5bae1d71239c7f8fb7d4ab67d | |
parent | 4a4cff4b437e60abd38c6229fabd79692e7fbd7d [diff] |
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)
These build rules are used for building Gerrit Code Review plugins with Bazel. Plugins are compiled as .jar
files containing plugin code and dependencies.
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()
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(name, srcs, resources, gwt_module, deps, manifest_entries):
<name>.jar
: library containing built plugin jar