497 Commits

Author SHA1 Message Date
Dave Borowitz
292fa154c1 Format all Java files with google-java-format
Having a standard tool for formatting saves reviewers' valuable time.
google-java-format is Google's standard formatter and is somewhat
inspired by gofmt[1]. This commit formats everything using
google-java-format version 1.2.

The downside of this one-off formatting is breaking blame. This can be
somewhat hacked around with a tool like git-hyper-blame[2], but it's
definitely not optimal until/unless this kind of feature makes its way
to git core.

Not in this change:
* Tool support, e.g. Eclipse. The command must be run manually [3].
* Documentation of best practice, e.g. new 100-column default.

[1] https://talks.golang.org/2015/gofmt-en.slide#3
[2] https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html
[3] git ls-files | grep java$ | xargs google-java-format -i

Change-Id: Id5f3c6de95ce0b68b41f0a478b5c99a93675aaa3
Signed-off-by: David Pursehouse <dpursehouse@collab.net>
2017-02-07 10:04:39 +09:00
Edwin Kempin
79e63a39e4 Revert external ID cache
It make more sense to include the commit SHA-1 of the notes branch from
which the external IDs have been read into the cache key. This makes it
easier to implement this cache within a multimaster setup.
However, obviously, we can include the commit SHA-1 of the notes branch
into the cache key only after the external IDs have been migrated to
NoteDb (because before this the notes branch does not exist yet).
Revert the cache for now and re-add an improved version of the cache
later with the change that implements the migration of the external IDs
to NoteDb.

This reverts the following commits:
- 2869caaf70569fcf777676d605f9d7e70c4ac36d:
  Add cache for external ids
- 48d5c9b9aa8aba3de52374328e2a1cc30be64a10:
  Make ExternalIdCacheImpl.AllKey public
- 20e5507d46c2a266e73974878685c74adfd6ff6b:
  ExternalIdCache: Add method to get external IDs by account ID + scheme

Change-Id: I589242aad32a9c70718542ba950c0a351c594e54
Signed-off-by: Edwin Kempin <ekempin@google.com>
2017-02-02 17:27:43 +01:00
Kasper Nilsson
de5dd7a2ef Add status field to account in ReviewDB
Adds a nullable string field to the account schema. Support in API to
come in a descendant change.

Feature: Issue 4394
Change-Id: Ib466221d15d2c90a78f78b5555ef98fa6d53ea07
2017-01-25 09:58:14 -05:00
Dave Borowitz
63fbea59ae Account: Minor cleanup
Remove unnecessary finals. Tidy up a column Javadoc.

Change-Id: Ic65faa7a369005fe93c474d8f22af4d790fb9bfd
2017-01-25 09:58:14 -05:00
David Ostrovsky
fdbfcad77d Remove Buck based build
Bug: Issue 5302
Change-Id: I6e860446ef30ff0ad1c7c49fc0e39d39d921820b
2017-01-23 12:44:58 +00:00
Edwin Kempin
2869caaf70 Add cache for external ids
Introducing a cache for external ids is a preparation step for moving
the external ids from ReviewDb into NoteDb. For NoteDb it is planned
to store the external ids in a git note branch, where the note keys
are the sha1's of the external ids and the note values contain the
external id, the account id and optionally email and password. With
this format we can easily lookup external ids by the external id, but
listing all external ids of an account requires parsing all external
ids. Looking up the external ids of an account is possible from the
account index, however for reindexing an account we would still need
to lookup all external ids of the account from git. Having a cache for
the external ids ensures that the external ids are only loaded once
from git. If there is any update to external ids, we take care to
update the cache as well. For this change it means that all code that
modifies external ids must do an extra call to update the external id
cache. This is not optimal since updating the cache can be easily
forgotten. This is why the follow-up change cleans this up by
introducing a dedicated class that handles all external id updates and
then this is the only class that must take care to update the external
id cache.

Change-Id: I9ea979c646cddb9b39e723de5c061a70a2ce6fd6
Signed-off-by: Edwin Kempin <ekempin@google.com>
2017-01-11 14:32:21 +01:00
Dave Borowitz
5a142312e9 Remove sequence-based UID generation for messages
Unique identifiers for ChangeMessages and PatchLineComments were
generated using a seed from a database sequence, mixed together with
IdGenerator. In the spirit of killing ReviewDb, use a
cryptographically secure pseudorandom number generator to generate
these IDs instead. Follow the same "xxxxxxxx_xxxxxxxx" format so IDs
look similar.

I suppose the goal of the sequence-based approach was to decrease the
chance of collision by including a piece of state in each ID that is
guaranteed unique across the server. However, the chance of collision
for any 8-byte identifier can never be less than 1/2^64 no matter what
implementation we choose.

By definition a cryptographically secure PRNG generates random data
that is evenly distributed across the entire byte space, so the PRNG
implementation also has a 1/2^64 chance of collisions; we're just
swapping one rare-collision implementation with another. (This assumes
no bugs or weaknesses in the PRNG implementation, but with all due
respect to Shawn, I don't think the JDK's PRNG is any more likely to
have collision-introducing flaws than our hand-written IdGenerator.)

This change actually has no effect on ChangeMessage IDs that are
stored in or read from NoteDb, because ChangeNotesParser always
populates the ChangeMessage UUID field with the SHA-1 in the notes
graph of the commit that introduced the message; ReviewDb UUIDs are
simply discarded. The messageUuid method is still called during
creation because of the implementation details of ChangeMessagesUtil,
but that ID is not used for storage.

This change does have an effect on the IDs generated for
PatchLineComments, which also use messageUuid for their IDs, despite
the somewhat confusing fact that the ReviewDb interface implies the ID
is just for ChangeMessages.

While we're in there, rename the method to messageUuid to match the
Google Java Style Guide for camelCase names.

Change-Id: I7d157b9e8f87b41d4e7a146b705012863c27d42e
2017-01-10 16:05:08 -05:00
Dave Borowitz
08cbca72e5 Merge "Add api portion of resolvable comments" 2017-01-05 21:19:01 +00:00
Dave Borowitz
62582a61dc Add all() methods to more ReviewDb access classes
Doesn't require a schema upgrade, as this is just more @Query methods,
not even backed by an index.

Change-Id: I47af680feada44d05f8014e1898e9e92f5f84269
2017-01-05 11:26:32 -05:00
Kasper Nilsson
7ec3036ab1 Add api portion of resolvable comments
With this change, the unresolved field of a comment is now set by the
value supplied in the request body. If no value is supplied, the value
of the parent is used, and if no parent exists then comments default to
unresolved=false.

Change-Id: I4d2e16e42a78473b78b4e5b044687df4c5554963
2017-01-04 17:00:17 -08:00
Edwin Kempin
b043d448a7 Migrate project watches to git (part 2)
This is the second part of migrating project watches from database to
git.

This change:
* bumps the database schema version
* migrates the project watches from database to git (for single
  instance Gerrit servers)
* deletes the database table
* deletes the user.readProjectWatchesFromGit config option

Change-Id: I9dc99f5483fdd72cf6e237236ed0b23f14b60249
Signed-off-by: Edwin Kempin <ekempin@google.com>
2016-12-29 11:23:56 +01:00
Edwin Kempin
10aa4e2bbf Require account index and remove fallbacks
The account data is moved from ReviewDb into git.

Change-Id: I643827179b24601b138f394cfff5890f919b9da9
Signed-off-by: Edwin Kempin <ekempin@google.com>
2016-12-29 11:23:56 +01:00
Edwin Kempin
e9070d639d Remove unused method AccountExternalIdAccess#byAccountEmail
Change-Id: I5f80d6e78069b0bab1e0cd22f9160f7d2a0ed984
Signed-off-by: Edwin Kempin <ekempin@google.com>
2016-12-21 14:41:48 +01:00
Alice Kober-Sotzek
110f60f082 Make the file path for the replacement of a robot comment explicit
Up to now, the file path was implicitly limited to the file on which
the robot comment was placed. This restriction will be relaxed in the
future. In order to not break systems which use the fix suggestions at
that (later) point in time, the mandatory field 'path' is introduced
with this change.

Change-Id: I73875b97bf844dee927720765046161bbd888c02
2016-12-19 16:45:26 +01:00
Kasper Nilsson
8a81cd1dae Upgrade schema for resolvable comments
Adds a boolean field to PatchLineComment to track whether or not the
comment thread is resolved. Also implements this field in NoteDB, albeit
not in a settable way.

Feature: Issue 4752, Issue 4879
Change-Id: I199248cbb83e1fadd1a366e265c0f490c3dabd90
2016-12-12 12:15:31 -08:00
ekempin
6b1cd81f90 Merge changes I69cf3fc4,Ib6e9e942
* changes:
  Add support for suggested fixes of robot comments
  Split long method into smaller ones
2016-12-07 15:01:27 +00:00
David Pursehouse
34321931e8 Merge "Remove test prefix from test methods"
* submodules:
* Update plugins/replication from branch 'master'
  - Remove test prefix from test methods in replication plugin
    
    We previously used 'test' to prefix tests but have decided to stop this.
    This change removes the prefix from all test code.
    
    Change-Id: I42e6191ece7872f4647e425e3ca0acf8c6452412
2016-12-07 12:48:37 +00:00
Alice Kober-Sotzek
bcd275eb7f Add support for suggested fixes of robot comments
With this change, suggestions for fixes can be provided with a robot
comment. At the moment, those suggestions are implicitly limited to the
file to which the robot comment was attached.

Change-Id: I69cf3fc4bdc66d69a5831b1e6c78937b8e945a72
2016-12-07 13:36:30 +01:00
David Ostrovsky
fa18907d7f Bazel: Reformat build files
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
2016-12-07 11:33:07 +00:00
Patrick Hiesel
a02a5c01e9 Remove test prefix from test methods
We previously used 'test' to prefix tests but have decided to stop this.
This change removes the prefix from all test code.

Change-Id: I229a36751adc6a87fbae8d6f373671e141529496
2016-12-06 10:36:42 +01:00
Dave Borowitz
8e917e11c2 Generalize Change.Id methods for parsing from refnames
Handle edit refs from Change.Id#fromRef, and add a new method
#fromAllUsersRef for parsing from refs in All-Users. Note that it's
not possible to combine these into one method that takes a project
name, since at this low level in the code we don't have access to the
live config-based AllUsersName.

Change-Id: I55ae5340efa964bbe7965a0a491ae27ce620044c
2016-11-30 11:53:22 -05:00
David Pursehouse
65afe7e3b2 RefNames: add constant for 'refs/meta/'
Change-Id: I01f78c20ecf4a445fbadbc20dbfc4044966f6767
2016-11-28 07:44:30 +00:00
David Pursehouse
926166ef94 Merge branch 'stable-2.13'
* stable-2.13:
  AccountSshKey: Strip newline characters out of public key string

Change-Id: Ia6d8973e347af80c945ef7b4bb19c79e03d91b89
2016-11-24 18:58:23 +09:00
David Pursehouse
a291706e96 AccountSshKey: Strip newline characters out of public key string
When an ssh public key is migrated from the database to the git backend,
it is stored in the authorized_keys file in the user's ref in All-Users.

If the public key has newlines, each line is read back as a separate key,
each of which will be considered invalid.

Strip newlines out of the public key string to prevent this situation.

Bug: Issue 4643
Change-Id: If3971fc1c432c79364206b2f3633db1629267ba0
2016-11-24 13:21:58 +09:00
David Pursehouse
1f9b0c76ef PatchSetApprovalTest: Extend GerritBaseTests
Remove the setup of KeyUtil which is now done in GerritBaseTests.

Change-Id: Ia84c41e3a21d0867e81d951e1b5a619953ead253
2016-11-22 10:05:47 +09:00
Han-Wen Nienhuys
888f4ac705 bazel: generate the classpath in a file, for use with eclipse.
Change-Id: I6562c045a7e47c6661889d63f3103e1aeef113ec
2016-11-14 23:23:56 -08:00
David Ostrovsky
b25f267f5d SystemConfig: increase site path length from 255 char to CLOB
Sandboxed unit tests are failing on CI: [1] because of too long site
path. Alter the size of the column from char 255 to CLOB.

[1] https://gerrit-ci.gerritforge.com/view/Gerrit/job/Gerrit-master-bazel/237/console

Change-Id: Ife55c0687d3c1f3ee7ba52626622ac8f35768a8d
2016-11-10 09:07:41 +01:00
Kasper Nilsson
1987154564 Add patch set description
With this change, the description field is properly populated by the %m
flag and set in ReviewDB and NoteDB, and is set in the ChangeJSON
received in a GetChange call. The test for pushing a change with a
message was also updated to check for the description field being set in
RevisionInfo.

To be included in descendant changes:
 - Handling cases where PSUtil.insert is called that aren't change
   creations or updates (cherrypick, etc)
 - Implementation of an API endpoint for setting/deleting the value
 - Docs

Feature: Issue 4544
Change-Id: I1c4d817d1d5e263b0cd42bf9ea874808aac00582
2016-11-08 10:26:31 -08:00
Dave Borowitz
7d8667d2cf Move refs/cache-automerge/ generation logic to RefNames
Change-Id: Id9b0c1364484205d435cb2f35469a0d95e439757
2016-10-31 15:46:10 -04:00
Dave Borowitz
e47fe47537 Support voting on merged changes
Historically, voting in Gerrit has always happened before a change is
submitted, and is an integral piece of the submit rule based workflow
for submitting changes. However, there are some circumstances where
reviewing a change after it has been merged is advantageous:

* when a change is merged into the branch by a direct push
* when a commit is merged bypassing Gerrit entirely, and a new change
  is created after the fact using the %merged push option (after
  I4de55806).

When this happens, it can be useful to not only write comments but
also vote on the merged changes.

Support this in Gerrit, and add a postSubmit bit to PatchSetApproval.
In NoteDb, this bit is populated automatically, based on whether an
approval happened after the change status was set to merged.

One major caveat is that PostReview enforces that votes can only be
increased, not decreased, for post-submit approvals. This limitation
exists for several reasons.

First, for normal changes that underwent pre-submit code review, we
assume that high review scores were necessary for submission. Allowing
scores to be reduced after the fact could make a change look like it
never should have been submitted in the first place. It should usually
be possible to figure out what happened by reading the message log
closely, but it's less confusing if we try to avoid this situation
entirely.

Second, since a submitted change is already a part of history, no
amount of negative voting on that change will cause the change to stop
being a part of history. (It could be removed via force push, but
that's outside of the code review.) Disallowing scores from being
reduced helps avoid the false impression that a negative score might
actually have some effect.

Finally, we want to enable developers to write tools that audit the
full commit history of a project and ensure that all commits have been
properly approved. These tools can make a major optimization by
assuming that once a change has been approved (e.g. has received
Code-Review+2), it can't be un-approved.

Change-Id: Ie337b5fa5261c873f3038e37300e8e626f9d6d3e
2016-10-14 10:16:43 +02:00
Dave Borowitz
a0f4942c5d ChangeNotes: Make defensive copies of mutable value types
ChangeNotesState stores immutable collections, but the actual
underlying ReviewDb types are frustratingly mutable. This means that
if a caller accidentally mutates an instance returned from the cache,
the cache can be polluted. In many cases this is mostly harmless,
since shortly after polluting the cache, the entry is rendered
obsolete by a NoteDb update. However, there are still cases where the
pollution can show up, for example if an exception is thrown from
PostReview after mutating an approval score.

Fix this by making more defensive copies in ChangeNotes. As a
compromise to avoid lots and lots of copies, only do this for types
that we expect to be mutable, namely PatchSet and PatchSetApproval.
Also don't worry about deep copying of ID types, which are technically
mutable but the Gerrit code never calls the setters for.

Change-Id: Iea647804b618422e1aade230fea5ebf6845198aa
2016-10-11 17:10:33 -04:00
David Pursehouse
793d78f140 Merge branch 'stable-2.13'
* stable-2.13:
  Squash event class private fire() methods into public methods
  GitReferenceUpdated: Remove redundant fire() methods
  Fire events with Account rather than Account.Id
  CreateProject: Use IdentifiedUser rather than CurrentUser
  Reduce visibility of helper methods in event classes
  Reduce log spam caused by event listener failures
  Organize imports
  init: Add a flag to force-delete the cache
  SetAccess: fix updating/visiting project access rules 500 error
  SetAccess: fix 500 error when no parameter `force` in access api
  init: delete cache if not empty
  GitReferenceUpdated: Declare listeners as DynamicSet
  PatchSetApproval: Set tag in copy constructor

Change Ie393f194e ("Fire events with Account rather than Account.Id")
caused compilation errors in PostReviewers. This merge also updates
PostReviewers to pass a list of Account rather than Account.Id.

Change-Id: I44bc12509143800b60abd47d6e49b8f545bc269e
2016-10-11 09:07:47 +09:00
Dave Borowitz
c230ccccb1 Record real user in database for approvals/messages/comments
Add a new field to PatchSetApproval, ChangeMessage, and
PatchLineComment that records the real user as reported by
CurrentUser. For compatibility with the old value in the database and
to avoid a migration, use null when the effective user is the real
user. However, in most other code, following the example of
CurrentUser, always return a non-null value from getters even when
effective and real users are the same.

On the NoteDb side, add a new optional footer and comment field
"Real-user" to indicate this situation. In NoteDb commits, leave the
effective user in the git committer field, reflecting the fact that
for most purposes, we care about the effective user, and have to look
a little closer to see whether there was another caller involved.

In theory we could add real user fields to other entities, like
Change and PatchSet, to reflect the fact that X-Gerrit-RunAs can be
used with arbitrary requests. However, for now, we are mostly
concerned explicit on_behalf_of support in PostReview and Submit, so
we only change entities that can be modified through those endpoints.

Change-Id: Iab5302f65321cc740376f4b4f117dd38b7496fc5
2016-10-10 12:01:03 -04:00
Edwin Kempin
6627074574 Support arbitrary properties on robot comments
Some robots have the need to store extra data on robot comments. UI
plugins can then use this data to show additional information for
robot comments or offer special action on them.

Change-Id: Ieb5f16554e1be4891f5835170790637f9f6726fc
Signed-off-by: Edwin Kempin <ekempin@google.com>
2016-10-10 16:59:41 +02:00
Dave Borowitz
c027596513 PatchSetApproval: Set tag in copy constructor
Change-Id: If110c207b2d04ffcb8c7f1fffcb27537faaa60e4
2016-10-05 10:50:02 -04:00
Edwin Kempin
3fde7e4e75 Add support for Robot Comments
Extend the PostReview REST endpoint to support posting of robot
comments. For this ReviewInput got a new field that can contain a list
of robot comments. For reading robot comments new REST endpoints have
been added.

Robot comments are only supported with NoteDb, but not with ReviewDb.

Robot comments are always stored as JSON, even if notedb.writeJson is
set to false.

In NoteDb robot comments are not stored in the change meta ref but in
a separate refs/changes/XX/YYYY/robot-comments ref. By storing robot
comments in a separate ref we can delete robot comments without
rewriting the history of the change meta branch which is needed for
auditing and hence cannot be rewritten. Deletion of robot comments is
not implemented in this change, but we may want to support this later
as the amount and size of robot comments can be large.

Draft robot comments are not supported, but robot comments are always
published comments.

Change-Id: I2d8a5ca59e9a8b2c34863c54a3a9576599f69526
Signed-off-by: Edwin Kempin <ekempin@google.com>
2016-09-28 15:34:54 +02:00
Gustaf Lundh
138aec1244 Assignee in ReviewDb.
Change-Id: I27c8823b349c79804c64207585d42f608d4319a8
2016-09-23 15:21:19 +02:00
Edwin Kempin
10ba6179cb Extract RevisionNote.Comment and use it instead of PatchLineComment
There are 3 classes that represent an inline comment:
- CommentInfo represents an inline comment in the REST API
- PatchLineComment represents an inline comment in ReviewDb
- RevisionNote.Comment represents an inline comment in NoteDb

To support robot comments CommentInfo and RevisionNote.Comment must be
extended so that the additional fields that are specific for robot
comments can be supported. PatchLineComment should not be touched
since robot comments will only be supported with NoteDb, but not with
ReviewDb.

At the moment PatchLineComment is also used to represent inline
comments in all middle layers and in all utility classes that deal
with inline comments. This means if NoteDb is used, inline comments
come in over REST as CommentInfo, then they are converted into
PatchLineComment and for storing them in NoteDb they are converted to
RevisionNote.Comment. The intermediate transformation to
PatchLineComment is bad for implementing robot comments, since this
class should stay unchanged.

To fix this RevisionNote.Comment is extracted into an own Comment
class and then Comment is used instead of PatchLineComment in the
middle layer. This means when NoteDb is used, inline comments are only
converted once, from CommentInfo to Comment. Both types will have
extensions for robot comments (by subtypes).

For storing inline comments in ReviewDb inline comments are converted
from CommentInfo to Comment to PatchLineComment. This is better than
having the double-conversion for NoteDb, because ReviewDb will be
removed in favour of NoteDb. This means when ReviewDb is removed
PatchLineComment can then easily be deleted, as it's no longer used
all over the codebase, but only in the ReviewDb layer.

Change-Id: I53481e8231e04aeca5b924e409e97b0f1d53f516
Signed-off-by: Edwin Kempin <ekempin@google.com>
2016-09-22 11:45:19 +02:00
Edwin Kempin
c6ea7bb81c Include a magic /MERGE_LIST file for merge commits
The /MERGE_LIST file is generated by Gerrit and is automatically
included in all changes for merge commits. It contains a list with the
commits that are integrated by accepting the merge commit. When
comparing against the auto-merge or a previous patch set it is assumed
that the first parent is uninteresting, so that the file lists all
commits which are reachable by the other parents, but not by the first
parent. If a comparison against a selected parent is done, that parent
is marked as uninteresting. This means the content of the file depends
on the selection in 'Diff Against' drop-down box.

By having the /MERGE_LIST file reviewers can immediately see which
commits get integrated by this merge commit. This is important since
for merge commits reviewers are supposed to review and approve these
commits. Having a file for this allow reviewers to comment on the list
and also see diffs between patch sets.

In edit mode the /MERGE_LIST file is not editable.

Change-Id: Iafcfe3f274ed334e9a40c13de5040a7509389e27
Signed-off-by: Edwin Kempin <ekempin@google.com>
2016-09-21 10:41:27 +02:00
Edwin Kempin
b5b60f3aed Patch: Add static method to check if file is magic
Many code places differentiate between regular files and magic files
(files that are generated and included by Gerrit). So far we only have
one magic file for the commit message and there is no big benefit of
having the static method to check for magic files. However we may add
other magic files and this is a preparation for this.

Change-Id: I1f7d77fc4e526916140e69deacdbde24cbe09c7c
Signed-off-by: Edwin Kempin <ekempin@google.com>
2016-09-21 10:33:58 +02:00
Dave Borowitz
e128d6f413 Java-8ify ReviewDbUtil
We can use method references within ReviewDbUtil to cut down on some
code. However, going through usages didn't show a uniform benefit to
using native Java 8 Comparator constructs. The naive replacement:

  comparing(Change.Id::get)

is shorter and more readable when it's correct, but it's not always
correct in the presence of nulls.

Ordering is also probably not going away from Guava, as it provides
some handy methods that are not (yet?) present on Comparator. For
example, creating a sorted copy of a Collection with Comparator is
arguably readable, but is not exactly short:

  myList.stream().sorted(comparing(Change.Id::get)).collect(toList())

Compared with the Ordering alernative:

  ReviewDbUtil.intKeyOrdering().sortedCopy(myList)

This benefit is greater when dealing with Iterable, which does not
have a readily available stream() method.

Leave some guidance in the intKeyOrdering Javadoc with advice.

Change-Id: Ib645abf060302cfc1c6d83f691e94f1dbf7c6db5
2016-09-21 02:40:31 -04:00
Dave Borowitz
e45363dcbd Use some Java 8 features
These suggestions were produced by a refactoring tool that we have;
the particular decisions it made were based on heuristics over which I
have no control. Some suggestions were edited for brevity, and to omit
references to unreleased Guava features.

Change-Id: I9deac0afd6eda8fdc5a369816a4ee2bbe16924ba
2016-09-20 15:39:47 -04:00
David Ostrovsky
0b774c478e Update Buck to latest version
This version fixed a major issue: [1] that was a reason of frustration
of many plugin developers: Not cache sources files under symbolic link.
Now for all such source files, the warning is issued:

"
Disabling caching for target //plugins/wip:wip__plugin, because one or
more input files are under a symbolic link
({plugins/wip=/home/davido/projects/wip}). This will severely impact
performance! To resolve this, use separate rules and declare
dependencies instead of using symbolic links.
"

To suppress this warning we add project.allow_symlink option. This
doesn't have any impact for gerrit core but silences the warning above
when plugins are built in gerrit tree mode.

As pointed out in this issue: [2], we are using some artifacts as source
to the java_library() rule as well as binary_jar for prebuilt_ja rule.
To avoid the warning, we rename sources to have "-sources.jar" suffix
and we rename *.zip to end with .jar in other places.

"
Assuming edit.src.zip is a JAR and renaming to edit.src.jar in
//gerrit-patch-jgit:edit_src. Change the extension of the binary_jar to
'.jar' to remove this warning.
"

source_under_test attribute was removed from java_test() rule.
Replication and cookbook-plugin are updated as well.

local.properties support was removed, but we use it only for download
process customization in our own python script, so that we can keep it
usage and not need to move it to .buckconfig.local.

[1] https://github.com/facebook/buck/issues/341
[2] https://github.com/facebook/buck/issues/855

Change-Id: Idf76cc71c21df43e808179b645f9175767b322a8
2016-09-20 13:19:15 +02:00
Saša Živkov
8af982ae60 Option to reject implicit merges when pushing changes for review
An implicit merge is a case where by submitting an open change one also
merges a branch into the target branch. Typically, this happens when a
change is done on top of master and, by mistake, pushed to stable
branch. Merging this change would also implicitly merge master into
stable.

Example 1:

  o < change pushed for stable
  |
  o < master
  |
  o < stable

  Submitting this change will implicitly merge master into stable:

  o < change pushed for stable, stable
  |
  o < master
  |
  o

Example 2:

           o < change pushed for stable
           |
  master > o   o < stable
            \ /
             o

  Submitting this change will implicitly merge master into stable:

               o < stable
              /|
            /  |
           o < change pushed for stable
           |   |
  master > o   o
            \ /
             o

A new project property receive.rejectImplicitMerges controls whether an
implicit merge will be rejected. When an implicit merge is detected
Gerrit will print error(s) to the user:

  remote: ERROR: Implicit Merge of 39adddb Commit message subject
  remote: ERROR: Implicit Merge of ...

and will reject the push.

Bug: issue 1107
Change-Id: I0b14c64bebe28ea5579fc11f6beedacf5982e5aa
2016-09-01 13:21:11 +02:00
Saša Živkov
225b7a78ee Option to reject implicit merges when pushing changes for review
An implicit merge is a case where by submitting an open change one also
merges a branch into the target branch. Typically, this happens when a
change is done on top of master and, by mistake, pushed to stable
branch. Merging this change would also implicitly merge master into
stable.

Example 1:

  o < change pushed for stable
  |
  o < master
  |
  o < stable

  Submitting this change will implicitly merge master into stable:

  o < change pushed for stable, stable
  |
  o < master
  |
  o

Example 2:

           o < change pushed for stable
           |
  master > o   o < stable
            \ /
             o

  Submitting this change will implicitly merge master into stable:

               o < stable
              /|
            /  |
           o < change pushed for stable
           |   |
  master > o   o
            \ /
             o

A new project property receive.rejectImplicitMerges controls whether an
implicit merge will be rejected. When an implicit merge is detected
Gerrit will print error(s) to the user:

  remote: ERROR: Implicit Merge of 39adddb Commit message subject
  remote: ERROR: Implicit Merge of ...

and will reject the push.

Bug: issue 1107
Change-Id: I0b14c64bebe28ea5579fc11f6beedacf5982e5aa
2016-09-01 11:50:11 +02:00
David Pursehouse
49d9a46904 Move AuthType from gerrit-reviewdb to extension API
Change-Id: I94d93e7776accd08d9d307781952b899ba13cbad
2016-08-23 17:27:50 +09:00
David Pursehouse
117b0e802b Account.FieldName: Move to extension API as AccountFieldName
Change-Id: I103dbe8bfaeb2acc67c6afd505c693953860bb0c
2016-08-23 10:28:45 +09:00
Alexandre Philbert
bfca2bbcd3 Remove leftovers of starred_changes for postgres index
Init would fail since the table doesn't exist.

Change-Id: I3cb795fc88c7448b50d9b28a4c341a4b130d58dc
2016-08-19 10:49:54 -04:00
David Pursehouse
6a7213456e PatchSet: Increase size of groups column
Increase the size to prevent running out of space when the number
of comma-separated groups is large. This can be the case when there
are a large number of merge commits in related changes.

The schema migration takes into account that the column might have
already been changed, in case anyone decides to do that manually on
an existing 2.12.x site.

Bug: Issue 4323
Change-Id: Icb3081b11e84f178516f650ff84acc6ee75045d3
2016-08-10 14:06:43 +09:00
Edwin Kempin
d73386ecbf Migrate project watches to git (part 1)
In git the project watch configuration of a user is stored in a
'watch.config' file in the refs/users/<sharded-id> user branch in the
All-Users repository.

The 'watch.config' file is a git config file that has one 'project'
section for all project watches of a project. This means if we ever
want to watch other entities we can add further sections in this file
(e.g. 'group' sections if we want to support watching of group
modifications).

The project name is used as subsection name and the filters with the
notify types that decide for which events email notifications should
be sent are represented as 'notify' values in the subsection. A
'notify' value is formatted as
"<filter> [<comma-separated-list-of-notify-types>]":

  [project "foo"]
    notify = * [ALL_COMMENTS]
    notify = branch:master [ALL_COMMENTS, NEW_PATCHSETS]
    notify = branch:master owner:self [SUBMITTED_CHANGES]

For a change event a notification will be send if any 'notify' value
of the corresponding project has both, a filter that matches the
change and a notify type that matches the event.

If two notify values in the same subsection have the same filter they
are merged on the next save, taking the union of the notify types.

For watch configurations that notify on no event the list of notify
types is empty:

  [project "foo"]
    notify = branch:master []

Unknown notify types are ignored and removed on save.

To support a live migration on a multi-master Gerrit installation, the
upgrade is done in 2 steps:

- part 1 (this change):
  * always write to both backends (database and git)
  * a configuration option (user.readProjectWatchesFromGit) decides if
    the project watches are read from database or git (default:
    database)
  * upgraded instances write to both backends, old instances only
    read/write from/to the database
  * after upgrading all instances (all still read from the database)
    run a batch to copy all project watches from the database to git
  * update all instances to read from git
  * make sure all instances use the new schema version of the account
    index
- part 2 (next change):
  * bump the database schema version
  * migrate the project watches from database to git (for single
    instance Gerrit servers)
  * delete the database table
  * delete the user.readProjectWatchesFromGit config option

This change requires that the account cache is manually evicted.

Change-Id: I4f8d4e8a762aeb4b46e27bb3bf9e58f91611145d
Signed-off-by: Edwin Kempin <ekempin@google.com>
2016-07-20 14:16:14 +02:00