A JUnit TestRule which enables to run the same JUnit test repeatedly.
This may help to identify the root cause why a flaky tests which succeed
most often does fail sometimes.
Add the RepeatRule to the test class containing the test to be repeated:
public class MyTest {
@Rule
public RepeatRule repeatRule = new RepeatRule();
...
}
and annotate the test to be repeated with the @Repeat(n=<repetitions>)
annotation:
@Test
@Repeat(n = 100)
public void test() {
...
}
then this test will be repeated 100 times. If any test execution fails
test repetition will be stopped.
Change-Id: I7c49ccebe1cb00bcde6b002b522d95c13fd3a35e
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
Type parameter T extends AnyObjectId in signature of update(String, T)
Change-Id: I9c13ddc572b8e94d5c7854f4de1f8206cb5e99ca
Signed-off-by: Matthias Sohn <matthias.sohn@sap.com>
The default author and committer objects in TestRepository were
initialized statically and did not use the MockSystemReader passed into
the TestRepository ctor. Make these fields non-static and initialize
them with a consistent clock.
Also make the author and commiter name and email strings public for
tests that want to verify against them.
Change-Id: I88b444b96e22743001b32824d8e4e03c2239aa86
Signed-off-by: Terry Parker <tparker@google.com>
ObjectInserter.Formatter and Git are autocloseable and can be
opened in try-with-resource to prevent a resource leak warning.
Change-Id: I48c4001aaa7d9c1e36369e9799bfbb7c3bb46d8b
Signed-off-by: David Pursehouse <david.pursehouse@sonymobile.com>
Require callers to pass in valid sets for both want and have
collections. Offer PackWriter.NONE as a handy constant for an
empty collection for the have part of preparePack instead of null.
Change-Id: Ifda4450f5e488cbfefd728382b7d30797e229217
Today there are plenty of modern build tool systems available in the
wild (in no particular order):
* http://bazel.io
* https://pantsbuild.github.io
* http://shakebuild.com
* https://ninja-build.org
* https://buckbuild.com
The attributes, that all these build tools have in common, are:
* reliable
* correct
* very fast
* reproducible
It must not always be the other build tool, this project is currently
using. Or, quoting Gerrit Code Review maintainer here:
"Friends, don't let friends use <the other build tool system>!"
This change is non-complete implementation of JGit build in Buck,
needed by Gerrit Code Review to replace its dependency with standlone
JGit cell. This is very useful when a developer is working on both
projects and is trying to integrate changes made in JGit in Gerrit.
The supported workflow is:
$ cd jgit
$ emacs <hack>
$ cd ../gerrit
$ buck build --config repositories.jgit=../jgit gerrit
With --config repositories.jgit=../jgit jgit cell is routed through
JGit development tree.
To build jgit, issue:
$ buck build //:jgit
[-] PROCESSING BUCK FILES...FINISHED 0,0s
Yes, you can't measure no-op build time, given that Buck daemon is
used.
Change-Id: I301a71b19fba35a5093d8cc64d4ba970c2877a44
Signed-off-by: David Ostrovsky <david@ostrovsky.org>
Some ancient objects may be broken, but in a relatively harmless way.
Allow the ObjectChecker caller to whitelist specific objects that are
going to fail checks, but that have been reviewed by a human and decided
the objects are OK enough to permit continued use of.
This avoids needing to rewrite history to scrub the broken objects out.
Honor the git-core fsck.skipList configuration setting when receiving a
push or fetching from a remote repository.
Change-Id: I62bd7c0b0848981f73dd7c752860fd02794233a6
Matthias Sohn
David Pursehouse
Terry Parker
Jonathan Nieder
XinTong Wang
David Pursehouse
Shawn Pearce
David Ostrovsky