gerrit_plugin_tests: stop implicitly creating Eclipse test deps gerrit_plugin_tests() currently creates <plugin>__plugin_test_deps whenever ext_deps is passed. Repeated test macros for one plugin then try to create the same java_library, which breaks BUILD files that split tests across several gerrit_plugin_tests() calls. One approach was to make this generated rule idempotent. That keeps the old behavior working, but it introduces heavy Starlark lifting: existing_rule() checks, label normalization, and validation of rule attributes generated by earlier macro calls. Another approach is to make <plugin>__plugin_test_deps explicit and reuse that target from gerrit_plugin_tests(). That avoids the idempotency machinery, but it mixes two different concerns: 1. Gerrit Eclipse classpath generation machinery expects a special test-only export target named <plugin>__plugin_test_deps. Plugins opt in through CUSTOM_PLUGINS_TEST_DEPS in tools/bzl/plugins.bzl. 2. Plugin BUILD files need additional test dependencies for Bazel test execution, also outside Eclipse. Use a compromise that keeps these concerns separate while allowing explicit reuse. ext_deps continues to mean Maven coordinates for Bazel test dependencies in gerrit_plugin_tests() and gerrit_plugin_test_util(), so existing plugin BUILD files keep working as-is. Add gerrit_plugin_ext_test_deps() for projects that need the Eclipse classpath helper. Add ext_deps_label to gerrit_plugin_tests() and gerrit_plugin_test_util() for projects that want to reuse that helper explicitly as the dependency carrier. There is no implicit creation or auto-discovery of <plugin>__plugin_test_deps from gerrit_plugin_tests(). ext_deps and ext_deps_label are mutually exclusive. Accepting both would make the resulting classpath ambiguous and could hide a divergence between the coordinate list and the reusable helper target. Migration path: * Keep gerrit_plugin_tests(ext_deps = EXT_DEPS) and gerrit_plugin_test_util(ext_deps = EXT_DEPS) for normal test deps. * Add one gerrit_plugin_ext_test_deps() call when Eclipse needs the <plugin>__plugin_test_deps classpath helper. * Optionally pass ext_deps_label = ":<plugin>__plugin_test_deps" to gerrit_plugin_tests() and gerrit_plugin_test_util() when Bazel targets should reuse that explicit helper target too. * Do not pass both ext_deps and ext_deps_label to the same macro call. * Keep skip_dependency_tests where repeated test macros would still generate duplicate dependency-test targets. Change-Id: I899320915162828727ed8eaaf749c5bb94393514
These build rules are used for building Gerrit Code Review plugins with Bazel. Plugins are compiled as .jar files containing plugin code and dependencies.
The setup depends on whether the plugin uses the deprecated Bazel WORKSPACE or has already transitioned to Bazel modules.
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_googlesource_gerrit_bazlets", remote = "https://gerrit.googlesource.com/bazlets", commit = "928c928345646ae958b946e9bbdb462f58dd1384", ) load("@com_googlesource_gerrit_bazlets//:gerrit_api.bzl", "gerrit_api") gerrit_api()
The version parameter allows to override the default API. For release version numbers, make sure to also provide artifacts' SHA1 sums via the plugin_api_sha1 and acceptance_framework_sha1 parameters:
load("@com_googlesource_gerrit_bazlets//:gerrit_api.bzl", "gerrit_api") gerrit_api(version = "3.2.1", plugin_api_sha1 = "47019cf43ef7e6e8d2d5c0aeba0407d23c93699c", acceptance_framework_sha1 = "6252cab6d1f76202e57858fcffb428424e90b128")
If the version ends in -SNAPSHOT, the jars are consumed from the local Maven repository (~/.m2) per default assumed to be and the SHA1 sums can be omitted:
load("@com_googlesource_gerrit_bazlets//:gerrit_api.bzl", "gerrit_api") gerrit_api(version = "3.3.0-SNAPSHOT")
When using a Bazel module, the plugin will have to install the Gerrit API in its MODULE.bazel itself:
# The name has to be unique module(name = "gerrit-plugin") bazel_dep(name = "rules_jvm_external", version = "6.10") bazel_dep(name = "com_googlesource_gerrit_bazlets") git_override( module_name = "com_googlesource_gerrit_bazlets", remote = "https://gerrit.googlesource.com/bazlets", commit = "928c928345646ae958b946e9bbdb462f58dd1384", ) GERRIT_API_VERSION = "3.12.0" gerrit_api_version = use_repo_rule( "@com_googlesource_gerrit_bazlets//:gerrit_api_version.bzl", "gerrit_api_version" ) gerrit_api_version( name = "gerrit_api_version", version = GERRIT_API_VERSION, visibility = ["//visibility:public"], ) maven = use_extension("@rules_jvm_external//:extensions.bzl", "maven") maven.install( name = "external_plugin_deps", artifacts = [ "com.google.gerrit:gerrit-acceptance-framework:" + GERRIT_API_VERSION, "com.google.gerrit:gerrit-plugin-api:" + GERRIT_API_VERSION, ], duplicate_version_warning = "error", fail_if_repin_required = True, fail_on_missing_checksum = True, fetch_sources = True, lock_file = "//:external_plugin_deps.lock.json", repositories = [ "https://repo1.maven.org/maven2", "https://gerrit-maven.storage.googleapis.com", ], version_conflict_policy = "pinned", ) use_repo(maven, "external_plugin_deps")
To use a snapshot version of the Gerrit API, add the file://-URL to the list of repositories in the MODULE.bazel file and adapt the GERRIT_API_VERSION- constant, e.g.:
GERRIT_API_VERSION = "3.11.0-SNAPSHOT" maven.install( name = "external_plugin_deps", artifacts = [ ... ], repositories = [ "file:///home/user/.m2/repository", "https://repo1.maven.org/maven2", "https://gerrit-maven.storage.googleapis.com", ], ... ) <a name="basic-example"></a> ## Basic Example Suppose you have the following directory structure for a simple plugin:
[workspace]/ ├── src │ └── main │ ├── java │ └── resources ├── BUILD └── WORKSPACE
To build this plugin, your `BUILD` can look like this: ```python load("//tools/bzl:plugin.bzl", "gerrit_plugin") gerrit_plugin( name = "reviewers", srcs = glob(["src/main/java/**/*.java"]), 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, deps, manifest_entries):
<name>.jar: library containing built plugin jarThis macro helps plugins track the set of third-party runtime dependencies that would be packaged into the plugin and detect accidental dependency changes in CI.
Example usage in a plugin BUILD file:
load( "@com_googlesource_gerrit_bazlets//tools:runtime_jars_allowlist.bzl", "runtime_jars_allowlist_test", ) runtime_jars_allowlist_test( name = "check_oauth_third_party_runtime_jars", allowlist = ":oauth_third_party_runtime_jars.allowlist.txt", hint = ":check_oauth_third_party_runtime_jars_manifest", target = ":oauth__plugin", )
To refresh the allowlist after an expected change:
bazelisk build //:check_oauth_third_party_runtime_jars_manifest cp bazel-bin/check_oauth_third_party_runtime_jars_manifest.txt \ oauth_third_party_runtime_jars.allowlist.txt
Optional arguments:
This macro helps plugins detect accidental bundling of third-party runtime JARs that are already shipped by Gerrit. It compares the plugin‘s packaged runtime JAR list against a provided manifest (for example Gerrit’s //:release.war.jars.txt) and fails on overlap.
This check is typically meaningful only when the plugin is built inside the Gerrit source tree where Gerrit's runtime manifest exists. Standalone plugin workspaces should gate the test via target_compatible_with so it is reported as SKIPPED rather than failing.
Example usage in a plugin BUILD file:
load( "@com_googlesource_gerrit_bazlets//tools:runtime_jars_overlap.bzl", "runtime_jars_overlap_test", ) load( "@com_googlesource_gerrit_bazlets//tools:in_gerrit_tree.bzl", "in_gerrit_tree_enabled", ) runtime_jars_overlap_test( name = "no_overlap_with_gerrit", target = ":my_plugin__plugin", against = "//:release.war.jars.txt", hint = "Exclude overlaps via maven.install(excluded_artifacts=[...]) and re-run this test.", target_compatible_with = in_gerrit_tree_enabled(), )
Optional arguments:
On failure, the test prints the overlapping normalized jar IDs and exits non-zero.
Some plugin tests and guardrails are meaningful only when the plugin is built inside the Gerrit source tree (e.g. checks that compare against //:release.war.jars.txt). Such checks should run when building in-tree, but be automatically skipped in standalone plugin workspaces.
Bazlets provides a typed Bazel build setting and helper to support this pattern.
load( "@com_googlesource_gerrit_bazlets//tools:in_gerrit_tree.bzl", "in_gerrit_tree_enabled", ) runtime_jars_overlap_test( name = "no_overlap_with_gerrit", against = "//:release.war.jars.txt", target = ":my_plugin", target_compatible_with = in_gerrit_tree_enabled(), )
In the Gerrit source tree, enable these checks by setting the following in .bazelrc:
common --@com_googlesource_gerrit_bazlets//flags:in_gerrit_tree=true
Standalone plugin workspaces should not set this flag. In that case, the corresponding targets are marked incompatible and reported as SKIPPED by Bazel.