You may want to pass arguments to the bazel build command line when
publishing, perhaps to debug output, or perhaps to add standalone flags
to avoid sandboxing on platforms where it is broken.
Change-Id: Ia1a9a50e7b833eea7299d9473dec87e4978b7803
Some platforms either don't have bash installed as /bin/bash. Use
the environment to find it in the PATH.
Change-Id: Ie1a6d64146927c83af07d0e2ca7f573c7504f8ef
Reformat the Bazel build files with the buildifier tool [1].
The style is different for Bazel files. Most notably, indentation level
is 4 spaces instead of 2, and " is used instead of '.
[1] https://github.com/bazelbuild/buildifier
Change-Id: I95c0c6f11b6d76572797853b4ebb5cee5ebd3c98
Ifec05b2f marked gerrit-server:testutil as test only, but missed to mark
as test only the targets that transitively depend on it.
Change-Id: Ia43ce915b3f98ba8231d316899118b849f1c4ad9
Current version was always true. Simplify it and make it actually work.
The check for unset variables is not needed also, because the generated
script doesn't have any, except $VERBOSE that must not be set.
TEST PLAN:
Verify that there is no noise (verbose output) from:
$ ./tools/maven/api.sh install bazel
$ ./tools/maven/api.sh install buck
Verify that there is verbose output from:
$ VERBOSE=1 ./tools/maven/api.sh install bazel
$ VERBOSE=1 ./tools/maven/api.sh install buck
Change-Id: I1cd0f4cadfa9cec0217c9bd76f5170c396aa3a12
Currently too big files are published, because some unwanted transitive
dependencies are included in the final artifacts. That will be fixed in
follow-up change by using neverlink option in java_library rule or using
provided_deps attribute that will be addded in future releases of Bazel:
[1].
TEST PLAN:
$ VERBOSE=1 tools/maven/api.sh install bazel
$ VERBOSE=1 tools/maven/api.sh install buck
* [1] https://github.com/bazelbuild/bazel/issues/1402
Change-Id: Ie73d4ae34d96be7f97f6329c4c30c814f54688d5
Whenever an error occurs in the api.sh script we want the script
to end and propagate the error upstream to whoever was invoking it.
This would allow the use inside a continuous integration system
and properly detect and notify failed or incomplete builds.
Change-Id: If64853d9c876e7f013bb96bcb911a6492d1a6ce6
Generated shell scripts for maven use a typical bash
if syntax which is not recognised by sh.
As a result the execution was failing on Gerrit CI.
(see [1])
Use bash as script interpreter to assure the correct
execution of the if statement.
[1]: https://goo.gl/3T5w5u
Change-Id: Id713a24d9cd6df145790769d014de6a66e64dace
The PEX wrapper ignores the exit code of the wrapped script, and
always exits with status 1, obscuring the true status of the command.
Since mvn.py doesn't use other libraries, we can just run it directly.
Change-Id: Ie7c3467cb3b8163cff79334a190fc29381dd2f72
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
When a maven command fails, the error message printed includes
the command which is rendered as a list.
Include the command as a string (joined list) so that it's easier
to copy and paste it, to run it manually and see the full output
from maven.
Change-Id: I95faf7b4464594950086bcddee891513779b4f24
This will allow a cleaner patch when forking Gerrit to deploy
to a different repository than the official release repository
on Maven Central.
Change-Id: Ic2ec2acb1fe9512782f8b1fe0b7e2ad2131e099d
The plugin and extension jars follow the scheme
gerrit-$FOO -> $FOO.jar
gerrit-$FOO -> $FOO-src.jar
gerrit-$FOO -> $FOO-javadoc.jar
Hence, for the gerrit-acceptance-framework directory, the artifacts
were expected as:
* gerrit-acceptance-framework.jar
* gerrit-acceptance-framework-src.jar
* gerrit-acceptance-framework-javadoc.jar
However, they are called 'api.jar', 'src.jar', 'javadoc.jar' without
any qualifier in front. To make naming more consistent, we make the
new gerrit-acceptance-framework artifacts follow the above scheme.
Change-Id: I6fcefed4a8ba05aae4ae2dc6f22ff39e48dea56d
Split the current gerrit-acceptance-tests in two parts:
* framework + some needed deps, that is exposed as additional plugin
artifact
* rest of the gerrit-acceptance-test project
To implement the split and not to pull in too many dependencies, some
refactoring was needed. Particularly, gerrit-server:testutil depends
on gerrit-server:server, that depends on almost everything. Similar
problem was with gerrit-pgm:pgm, that is needed for AbstractDaemonTest
to work. Split the rules in gerrit-pgm to break transitive dependency
chain. We shouldn't ship artifacts twice, in plugin-api and in
acceptance-framework.
This change also partially reverts Ie9e63de622, where
//gerrit-acceptance-tests:lib with all its transitive dependencies was
included in plugin-api artifact.
Expose gerrit-acceptance-framework as new plugin artifact. This allows
us to support unit tests in plugins in three different build modes:
* Buck in tree build mode
* Buck standalone build mode
* Maven build
To install gerrit-acceptance-framework locally, the following command
is used:
buck build api_install
To deploy gerrit-acceptance-framework to Maven Central, the following
command is used:
buck build api_deploy
To support unit tests in tree build mode, the following Buck variable
is exposed: GERRIT_TESTS and can be used, e.g.:
java_test(
name = 'cookbook_tests',
srcs = glob(['src/test/java/**/*IT.java']),
labels = ['cookbook-plugin'],
source_under_test = [':cookbook-plugin__plugin'],
deps = GERRIT_PLUGIN_API + GERRIT_TESTS + [
':cookbook-plugin__plugin',
],
)
To support unit tests in standalone build mode, acceptance-framework
maven jar is defined in lib/gerrit/BUCK file:
maven_jar(
name = 'acceptance-framework',
id = 'com.google.gerrit:gerrit-acceptance-framework:' + VER,
license = 'Apache2.0',
attach_source = False,
repository = REPO,
)
bucklets/gerrit_plugin.bucklet is extended with the same variable
that points to the new maven_jar artifact, so that the same Buck
java_test() rule can be used in both modes.
Test plan:
1. run tests in gerrit tree
2. apply corresponding change to cookbook-plugin and run tests in
gerrit tree mode
3. apply corresponding change to bucklets, and run tests for
cookbook-plugin in standalone build mode
Change-Id: I4cadf6616de36ca24712f8b07d282b7a50911105
Buck extensively uses caching and storing metadata in buck-out
directory, so that it's not possible per design to re-trigger the
execution of custom rule, without wiping out the whole buck-out
directory. See also the discussion on this issue: [1].
The implementation of Maven deployment as a custom build rule with
a side effect is wrong approach to start with. It was only done as a
workaround, because buck doesn't offer `install` or `publish` command
that must not be free of side effects like it's the case with `build`
command. Having side effects with `build` command breaks bucks model.
As workaround for now add standalone Python script, that re-uses Buck
api_{deploy|install} targets, resolves $(location <target>) macros and
executes the deployment by calling mvn.py utility directly:
$ tools/maven/api.py {deploy,install}
Dry run mode is supported as well:
$ tools/maven/api.py -n {deploy,install}
[1] https://github.com/facebook/buck/issues/342
Change-Id: I7fb86ad6967a1fa1e7ac842ba5e0e8cf0103b773
Use the canonical syntax to specify the python executable to use.
Avoids a fatal error if /usr/bin/python is a too old version (< 2.7).
Change-Id: I3e8affb52be993d35c0dcf90774d962a59ef5635
Since [1] dependencies to targets used in $(exe //path/to:target) and
$(location //path/to:target) macros are added implicitly.
[1] https://github.com/facebook/buck/issues/128
Change-Id: Id98257e1118830205821e35816d0e562e56e961a
The check_output method is only available from Python 2.7, so a wrapper
method was introduced for compatibility with 2.6.
The ZipFile class does not include context manager support in Python
2.6, so the file download code was written to explicitly open and close
the zip files.
Since Buck itself now requires at least Python 2.7, these workarounds
are no longer necessary. Remove them.
Also, tidy up a few minor PEP-8 coding style violations in the modified
files.
Change-Id: I9a1b25ddf7494e25ccadeaed0c1d85cd1ce2fd09
Since the last Buck upgraded this morning with [1]
the root path resolution is broken.
This is due to the different expansion of the __file__
macro into a deeper structure, including the python
relative path name inside a PEX directory structure.
Example:
gerrit/buck-out/bin/tools/maven/mvn.pex/gerrit-extension-api/pom.xml
In order to go back to the root package structure
and locate the pom.xml file correctly, we need now
to go back until the .buckconfig file is found
(instead of going back exactly 3 times as it was before).
P.S. Without this change the targets api_install
and war_install are broken on master.
Change-Id: I1a99606ad304c245b21ba501f15c473142a89fc2
Switch deploying Gerrit extension and plugin API from Google storage
bucket to Maven Central.
To simplify the troubleshooting new trace option was added to
underlying python script. When environment variable VERBOSE=1
is set, then the mvn command is printed to stderr:
VERBOSE=1 buck build api_deploy_oss
Change-Id: I9ebe44ec8aca91aa6b5514f561209e7c50377927
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 patch adds gerrit.war into api_{install,deploy} buck build step.
This allows third party maven based builds depend on gerrit.war
artifact.
Change-Id: I22c8d3339a1647913967e423e45462c2c5c255de
Signed-off-by: Dariusz Luksza <dariusz@luksza.org>
* stable-2.8:
Update 2.8.2 release notes with recently merged changes
Update change to invalidate cache after deletion of draft revision
Buck: Decouple plugin-api installation from deployment
SideBySide2: Fill the browser width
SideBySide2: Fix tab alignment to be correct width
Extend ChangeScreen2 horizontal bars to full width.
Conflicts:
gerrit-gwtui/src/main/java/com/google/gerrit/client/change/ChangeScreen2.ui.xml
gerrit-gwtui/src/main/java/com/google/gerrit/client/diff/DiffTable.ui.xml
Change-Id: Ie78dbe4f7c6695be273a78e4fe44a2d4081aed7e
Currently the same pom_fake.xml controls both installing the plugin-api
in local Maven repository (typical use case for a contributor) and
deploying it on Google bucket (typical use case for a maintainer). To fit
the both use cases that file contains stuff needed for uploading to Google
bucket only: 'gs-maven-wagon' artifact and the repository to fetch it from.
Because the "best" build tool in the world randomly and unreproducible
fails to fetch that artifact [1], frustrating the potential contributors,
for reasons that nobody knows and understands, separate these use cases
from each other, and strip the stuff from pom_fake.xml needed for deployment
of plugin-api. The cost is code duplication. The advantage of doing it:
buck build api_install
just works. Always.
[1] https://gist.github.com/mulby/092fee5f5962aafbbb25#file-gerrit-build-error-txt
Change-Id: I842335907ef8721f4126bcd90e395f7748aefc74
Currently the same pom_fake.xml controls both installing the plugin-api
in local Maven repository (typical use case for a contributor) and
deploying it on Google bucket (typical use case for a maintainer). To fit
the both use cases that file contains stuff needed for uploading to Google
bucket only: 'gs-maven-wagon' artifact and the repository to fetch it from.
Because the "best" build tool in the world randomly and unreproducible
fails to fetch that artifact [1], frustrating the potential contributors,
for reasons that nobody knows and understands, separate these use cases
from each other, and strip the stuff from pom_fake.xml needed for deployment
of plugin-api. The cost is code duplication. The advantage of doing it:
buck build api_install
just works. Always.
[1] https://gist.github.com/mulby/092fee5f5962aafbbb25#file-gerrit-build-error-txt
Change-Id: I842335907ef8721f4126bcd90e395f7748aefc74
This plugin module was left out during Buck migration.
$>buck build api
produces now plugin-gwtui.jar and plugin-gwtui-src.jar.
Buck Maven bridge was enhanced to {install|deploy} the new artifact to
remote or local Maven repositories:
$>buck build install_api
deployes
gerrit-plugin-gwtui-2.9-SNAPSHOT-sources.jar
gerrit-plugin-gwtui-2.9-SNAPSHOT.jar
to local Maven repository.
Change-Id: Idae18f6df2e67fe53d57b8c35caa4226333e269b
(cherry picked from commit c8cffc8e928a9277621ffff6cb740f79cd662195)
Add the necessary settings in the fake pom.xml file, and correct the URL
in the BUCK file to make deployment with gs-maven-wagon work.
Change-Id: I6d1f84c850c70f731d061d9e50a062d37c68baf2
Since this Buck's commit 59759043f66de17140b423a7f11a2d8827b4cbbf the whole
unflattened subtree is used.
Change-Id: I4ec930a452d4867add3f5dd46430d3184c2a7277
buck build api
generates now javadocs.
buck build api_install
installs all plugin/extension related artifacts with javadocs in the
local Maven repository.
Change-Id: Ifa6a8eb469f388e16449576ff2bff01a5dce67dd
This plugin module was left out during Buck migration.
$>buck build api
produces now plugin-gwtui.jar and plugin-gwtui-src.jar.
Buck Maven bridge was enhanced to {install|deploy} the new artifact to
remote or local Maven repositories:
$>buck build install_api
deployes
gerrit-plugin-gwtui-2.9-SNAPSHOT-sources.jar
gerrit-plugin-gwtui-2.9-SNAPSHOT.jar
to local Maven repository.
Change-Id: Idae18f6df2e67fe53d57b8c35caa4226333e269b
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
The correct reference to the action name is args.a. action is an old
variable that was replaced by args.a and this reference was missed.
Bug: issue 2086
Change-Id: Ibfbf523db8a8adfbf72f31de3ddc7b0ec96014eb
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
