To run the tests:
bazel test //...
To build the Gerrit plugin API, run:
bazel build gerrit-plugin-api:plugin-api_deploy.jar
To build the Gerrit extension API, run:
bazel build gerrit-extension-api:extension-api_deploy.jar
TODOs:
Licenses
Reduce visibility (all public for now)
Generate HTML Documentation
Core plugins
gerrit_plugin() rule to build plugins in tree and standalone modes
GWT UI (only gwt_module() skylark rule is provided, no gwt_binary())
PolyGerrit UI
WAR
Publish artifacts to Maven Central
Ask Bazel team to add Gerrit to their CI on ci.bazel.io
Contributed-By: Han-Wen Nienhuys <hanwen@google.com>
Change-Id: I9a86e670882a44a5c966579cdeb8ed79b1590de3
This eliminates the last Makefile in our code base.
Also change the section style within ReleaseNotes from asciidoc style to
asciidoctor style.
Also I feel that put images/link.png under ReleaseNotes and deal with
all the resource packing is too stupid, so I used the unicode emoji
instead of the picture ("🔗"). If this is too crazy, we can also use "#"
instead :) This also affects documentation rendering.
Other side effects:
1. The css of release notes switched from default asciidoc css into
default asciidoctor css.
2. The section anchors for ReleaseNotes/index.html changed from "2_13"
to "s2_13", because asciidoctorj is unhappy with anchors without
letters.
Change-Id: I4adf2ce090385cc6b699445012f10a009892aaac
Build actions can be cached, so they can't be used for Maven
interactions. Instead, generate a script that calls buck and then
runs the upload process.
This obviates tools/maven/api.py.
The script tools/maven/api.sh runs all deployment steps combined
(generate script, generate artifacts, upload to maven.)
Tested:
Ran "python tools/maven/api.py -n deploy" before and "buck
build //tools/maven:gen_api_deploy" afterwards. The old command line
and generated script differ as expected:
* paths in the script are absolute, because Buck expands $(location)
to absolute paths.
* the ordering of arguments differs, because Python dict iteration
was random beforehand.
* "-o" missing afterward, as expected.
The same check was performed for gen_api_install.
Change-Id: Ia246000f8b59e881c53265751e2ebcfe8ec7d433
Due to known issue: [1] we need to ignore lib/jgit directory for now,
which will stop Buck from trying to parse //lib/jgit:something and only
use the @jgit//:something.
This update brings some performance improvements. Notable changes
include:
- Buck now caches its Action Graph, which is part of the Parsing phase.
Large projects should see this step speed up.
- A massive performance win (200x on HFS+ and 20x on ext4) when crawling
the filesystem for build files (common during commands like buck
project or buck build //...) when using watchman.
- The disk cache of Buck is now structured differently and performs
better as a result on some filesystems.
- Fixed a bug that would cause buck to hang if you had a build file that
didn't parse.
[1] https://github.com/facebook/buck/issues/717
Change-Id: I46cd6ee9885cbe9514fae46e3df00e959d32e1b3
Consume JGit as first third party library from its own cell. Normally
the cell is defined as lib/jgit directory. It can be easily replaced
with CLI:
buck build --config repositories.jgit=path/to/dev/jgit gerrit
or tweaking the .buckconfig:
[repositories]
jgit = path/to/dev/jgit
The former approach is sufficient to build and run the test from the
CLI, the latter is needed to generate eclipse project.
To isolate the JGit rules in its own cell some refactoring was needed.
JGit patch for GWT module was moved to gerrit-patch-jgit project, and
some symlinks were needed for maven machinery to work. include_defs()
doesn't work for now across cell boundaries, and native `buck fetch`
feature still has some limitations: [1]. Moreover, excluding paths,
unsigning JARs and license linking should be re-implemented on top
of it.
[1] https://github.com/facebook/buck/issues/602
Test Plan:
Normal gerrit build and the build with hijacked JGit cell should work
in both standalone (gerrit.war) and Eclipse environment. Note, that
to test --config repositories.jgit=path/to/dev/jgit use case, the most
recent JGit tree must be used, that contains Buck driven build
implementation.
Change-Id: I39f2d5d75bbac88804406d6242b5e714f4916926
The new Buck version fixed macro resolution in cross-cell context: [1],
[2]. Moreover, new version includes number of performance improvements:
* parallel BUCK file parsing
* spooling Java class files directly to jar, without intermediately
storing them on disc
Currently these features are not activated by default, so we have to
manually turn them on.
[1] https://github.com/facebook/buck/issues/544
[2] d2cffbd60d
Change-Id: I133347ad7e963107bea637ece6cd3ee80842d802
The new Buck version fixed annoying stdout spamming bug on unit test
failures: [1]. Now we can revert our monkey patching hack to prevent
that.
Since [2] Buck interferes with files in buck-out directory: [3]. Switch
to using eclipse-out directory as Eclipse output directory instead. For
this change it's necessary to clean up buck-out directory, otherwise
`buck test` would fail.
This version also fixed "Python client lost connection" bug: [4].
This reverts commit 94e93aaad22e67b5956627cff1a9cb84d03a29ec.
[1] https://github.com/facebook/buck/issues/505
[2] 35cb495b57
[3] https://github.com/facebook/buck/issues/527
[4] https://github.com/facebook/buck/issues/534
Change-Id: I4cd1a99ce9d0615713c235d873e6cdd61b1854bb
Introduce new :gwtgerrit target that only depends on non optimized GWT
UI module. For one that accelerates artifact creation, as in development
the optimized UI module is not needed, for another it skips building
PolyGerrit dependencies. As a side effect of this change, PolyGerrit is
not bundled any more, when safari or firefox user agents are used.
Change-Id: Ib908a8e3b840deae0a6f0899794dc37bc3526cb6
Since Buck has no native support for web tests, wrap the tests in a
Python shim that calls wct. As in other Polymer cases, we need to
prepare a set of inputs and create a directory containing exactly what
wct expects to be there. Buck exposes resources to python_tests using
the pkg_resources API, which is cumbersome to use, and easier just to
ship around zip files as we do elsewhere.
Unlike other npm binaries we've encountered, the web-component-tester
module has numerous native dependencies, up to and including Selenium.
Rather than get in the game of distributing platform-specific
binaries, punt and require `wct` to be on the user's $PATH for now.
Tests are currently excluded in .buckconfig but can be run directly
with either:
buck test //polygerrit-ui/app:polygerrit_tests
buck test --include web
Change-Id: Ia314213925ac27ff271374a96ed539fb2acf0187
Developers working on the PolyGerrit UI shouldn't have to wait an
extra 30-60s to build the GWT UI into the binary.
Change-Id: If2958a9b09d9a998cf2ab00b0ee60e62d8dee564
Since [1] genrule() target doesn't accept deps parameters any more.
As replacement, cmd should use $(location :foo) macro. Reshuffle some
rules to fix existing genrule targets. Remove all rule, as it cannot
depend any more on api and release. Moreover create all.zip with both
api.zip and release.war included doesn't make really sense. Adjust the
documentation correspondingly.
gen_licences.py is accepting first order dependencies and computes the
classpath on its own. Make it work for now by passing the classpath for
the dependencies. Add a TODO to clean this up and accept the classpath
from the Buck side, similar to what was done in Ifd2dcf69aa.
[1] d2c6edbf7b
Change-Id: Iab403cd964d09aff652662cd18b020db8e07a0d9
Downloaded artifacts went directly into
~/.gerritcodereview/buck-cache
while artifacts built by BUCK went into the directory's `cache`
subdirectory:
~/.gerritcodereview/buck-cache/cache
. When just walking the file hierarchy on the command line, this
`cache` sub-directory is hardly visible, due to all the downloaded
artifacts. To increase visibility, we change to
* ~/.gerritcodereview/buck-cache/downloaded-artifacts
(for downloaded artifacts)
* ~/.gerritcodereview/buck-cache/locally-built-artifacts
(for artifacts built by buck locally)
That way `~/.gerritcodereview/buck-cache` (instead of one directory
and 100s files) now only contains two directories.
Change-Id: I7327ff6c1736f9af8ea15450949dc6a4bc10b684
DisableCastChecking option was first added in I5dc633d5b. Since Issue
3389, that caused breakage of all Google products for many weeks, this
option is added again in the development build to prevent such severe
regressions in future.
Because the generated javascript code is bigger with cast checks, this
option is still added in release mode.
Side effect of this change is that the plugins that expose GWT module
are compiled without DisableCastChecking option in Gerrit tree mode.
Standalone bucklets driven build mode is not affected by this change.
Another side effect, that 'soyc' target for "compiler story" was
duplicated and the corresponding release mode with DisableCastChecking
is also provided with alias 'soyc_r'.
TEST PLAN:
$ buck build gerrit
should pass only -XdisableClassMetadata option to GWT compiler. Whereas
$ buck build release
should pass both -XdisableClassMetadata -XdisableCastChecking options.
Bug: Issue 3389
Change-Id: Ia99647357e7bff889137d4855e9c0059e6c6a4f3
The GWT compiler can output a report (or "story of your compile"),
describing the size of the JavaScript and which source classes
contributed to the overall download size. This is useful for
optimizing code splits in Dispatcher, and generally understanding
the impact of linking code together.
Only the "Split Point Report" is created.
The "Compiler Metrics" are not output.
The report is very slow to create, so it is not done by default.
Change-Id: I6ce86d65ee5f3e4bdba573d1f777ccc59767341d
Add rule to build search-free documentation for static hosting, and update
dev-release documentation to reflect the new rule.
Change-Id: Ifc9284d3c44349e3099ad582fcc14ba27695f30a
The codeserver runs separately and cannot easily be embedded in Gerrit
because it depends on an outdated version of Jetty. We may change this
behavior when GWT is updated.
Prerequisite is to download gwt-codeserver.jar and dependencies:
buck build codeserver
Start CodeServer with new launch configuration:
tools/eclipse/gerrit_gwt_codeserver.launch
And follow the instructions: [1].
[1] http://stackoverflow.com/a/18333050/116472
Inspired-By: Thomas Broyer <t.broyer@gmail.com>
Change-Id: Ieff7190db6bc151eae1274105ccf828eaa652027
* stable-2.9:
Fix GitWeb link for parent commits
Move gerrit.war from api_{install,deploy} to war_{install,deploy}
New review UI: Fix display of large avatar image in user popup panel
Conflicts:
.buckconfig
Change-Id: I3ec139fb5b95fc443be834fba8866528e7a51ab2
I22c8d3339 added unconditionally installation of gerrit.war to API install
process. Because it depends on '//:release' target all core plugins,
documentation and optimized permutations of all supported GWT client
agents must be built to update a new version of plugin API.
In some cases it cannot be built at all, i.e. if Gerrit tree was cloned
non-recursively, and core plugins are not available.
Very repetitive tasks in development process like building new version of
plugin API that other plugins depend on should be very easy and fast doable.
Decouple installation and deployment of gerrit.war in its own targets:
$ buck build war_{install,deploy}
Change-Id: I7fce3b126621580dde43104aa811d704cf6e8997
This change allows to compile optimized GWT version for popular brwosers:
buck build chrome
buck build firefox
buck build safari
And no: IE is not among them:
buck build ie
BUILD FAILED: No directory ie when resolving target //ie:ie
Change-Id: I4f888bd114928555967022c5586e2b3ef16396b0
Use buck-out/cache folder for local cache of buck build results.
Since we don't (yet) have a shared set of Cassandra cache nodes,
using a local cache is a good default. This will speed up build
times when switching between different version of Gerrit (for example
master/stable) and also when running "git bisect".
Change-Id: Id23c6053e7cb0498d129345f6ead18288d0e9701
genrule() no longer supports running commands run only for the
side-effect with no output file. Actions like download_sources or
eclipse need to be handled using Python scripts executed from the
user's shell, otherwise Buck fails if caching is enabled.
Change-Id: I361fc20675f211e15e4ab7942ef52778d0a615c2
According to [1] buck makes no assumption about source code versioning
systems which means that it will also scan the .git folder for the file
system monitoring (buckd) and when searching for the BUCK files.
[1] http://facebook.github.io/buck/concept/buckconfig.html
Change-Id: Ic9248326232684f8b85a951f5b01b542127a080a
The build system used mixed names for essentially the same things.
Rename all DEFS files to *.defs matching the handful of other files
that are already using this convention.
Change-Id: I3269bd5db5d8d83f5e192ea910f19431c2a4a1cf
These are already named using the alias in the .buckconfig. Moving
them down to tools allows their program to drop a visbility rule, and
shortens the top level file a bit.
Change-Id: I4193249c02850cb7aca3bf7fab81113c5f7b7d8b
Rewrite the Maven tool to accept a spec of things to process on the
command line and use $(location) in the invoking genrule() to locate
the necessary files from Buck. This gets rid of special cases in the
mvn wrapper tool and allows the definition to be given completely from
Buck as part of the build description.
Maven needs to be single threaded to perform repository updates safely
so only one genrule() target is declared to buck for the deploy or
install action. The rule is given all artifact information in a single
pass, allowing the mvn.py wrapper to execute them.
Change-Id: Idbcf645b69280420987a0e8f52947ba93ac9e6f0
`buck build api_install` copies the artifacts to the local maven repository.
`buck build api_deploy` uploads the artifacts to the remote maven repository.
The type of the repo is induced from the Gerrit version name, i. e.
* 2.8-SNAPSHOT: snapshot repo
* 2.8: release repo
Change-Id: I063834bb39311a4d92f5fdbb183f70b1fb8418b6
The macro rules this file defines have nothing to do with the
third-party dependency libraries, but instead are global definitions
used throughout the Gerrit build process. Most build tools are
hidden under //tools, so move these definitions to that directory.
Change-Id: I5e95d7cef734228ca818428a266afc0ac9fa0385
Previously it also setup the prebuilt_jar() which isn't actually
necessary to execute the download. This reduces the size of the
command line passed into the child buck process.
Before this change not all libraries were downloaded during the
download target. Targets in the root of //lib were skipped due to
an incorrect regex passed to egrep. This has been fixed with the
new regex inside of download_all.py.
The initial binary download now requires ~59s on my home cable modem,
and pulls 84M.
Source JARs are now only downloaded when the user builds the
download_sources target. This saves ~30s of setup time on a
the same connection and reduces the initial download by 16M.
Change-Id: Ie3bc97c9101c94f8bc4b89664bbd218323ad7230
Try to reduce the size of the top-level BUCK file by moving
anything that has to do with Eclipse project generation and
classpath management into tools/eclipse.
Change-Id: Id779eaff4fe732908b28a8e3441004e364b59e21
This avoids needing to type ":" in front of the name to build.
Eventually I can move the eclipse targets down into a different
area and hide them from the top level file.
Change-Id: I9781099348cbe969bfd9c1f38711c37e1b92d3e2
Implement a new build system using Buck[1], Facebook's
open source clone of Google's internal build system.
Pros:
- Concise build language
- Test and build output is concise
- Test failures and stack traces show on terminal
- Reliable incrementals; clean is unnecessary
- Extensible with simple blocks of Python
- Fast
buck: clean: 0.452s, full 1m21.083s [*], no-op: 7.145s,
mvn: clean: 4.596s, full 2m53.776s, no-op: 59.108s,
[*] full build includes downloading all dependencies,
time can vary due to remote server performance.
Cons:
- No Windows support
- No native Maven Central support (added by macros)
- No native GWT, Prolog, or WAR support (added by macros)
- Bootstrap of buck requires Ant
Getting started:
git clone https://gerrit.googlesource.com/buck
cd buck
ant
Mac OS X:
PATH="`pwd`/bin:/System/Library/Frameworks/JavaVM.framework/Versions/Current/Commands:$PATH"
Linux:
PATH="`pwd`/bin:$PATH"
Importing into Eclipse:
$ time buck build :eclipse
0m48.949s
Import existing project from `pwd`
Import 'gerrit' (do not import other Maven based projects)
Expand 'gerrit'
Right click 'buck-out' > Properties
Under Attributes check 'Derived'
If the code doesn't currently compile but an updated classpath
is needed, refresh the configs and obtain missing JARs:
$ buck build :eclipse_project :download
Running JUnit tests:
$ time buck test --all -e slow # skip slow tests
0m19.320s
$ time buck test --all # includes acceptance tests
5m17.517s
Building WAR:
$ buck build :gerrit
$ java -jar buck-out/gen/gerrit.war
Building release:
$ buck test --all && buck build :api :release
$ java -jar buck-out/gen/release.war
$ ls -lh buck-out/gen/{extension,plugin}-api.jar
Downloading dependencies:
Dependencies are normally downloaded automatically, but Buck can
inspect its graph and download missing dependencies so future
compiles can run without the network:
$ buck build :download
[1] http://facebook.github.io/buck/
Change-Id: I40853b108bd8e153cefa0896a5280a9a5ff81655
