[ANNOUNCE] Gerrit 2.9

1,308 views
Skip to first unread message

Edwin Kempin

unread,
Jul 18, 2014, 7:35:59 AM7/18/14
to Repo and Gerrit Discussion

Edwin Kempin

unread,
Jul 18, 2014, 7:42:25 AM7/18/14
to repo-d...@googlegroups.com
The 2.9 plugin artifacts are available on Maven Central:
  http://central.maven.org/maven2/com/google/gerrit/

Will Saxon

unread,
Jul 18, 2014, 9:24:59 AM7/18/14
to repo-d...@googlegroups.com
Sort of related: is there a central/official location for binaries of the other plugin projects?

Edwin Kempin

unread,
Jul 18, 2014, 9:32:39 AM7/18/14
to Will Saxon, Repo and Gerrit Discussion
2014-07-18 15:24 GMT+02:00 Will Saxon <sax...@gmail.com>:
Sort of related: is there a central/official location for binaries of the other plugin projects?
Not yet. It would be nice to publish them on Maven Central too.

Luca has setup a public build for most plugins from where the binaries can be downloaded.
I just don't have the URL at hand.
@Luca: Can you share it again?
 


On Friday, July 18, 2014 7:42:25 AM UTC-4, Edwin Kempin wrote:
The 2.9 plugin artifacts are available on Maven Central:
  http://central.maven.org/maven2/com/google/gerrit/

Am Freitag, 18. Juli 2014 13:35:59 UTC+2 schrieb Edwin Kempin:

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

David Ostrovsky

unread,
Jul 18, 2014, 9:41:26 AM7/18/14
to repo-d...@googlegroups.com

Am Freitag, 18. Juli 2014 15:32:39 UTC+2 schrieb Edwin Kempin:



2014-07-18 15:24 GMT+02:00 Will Saxon <sax...@gmail.com>:
Sort of related: is there a central/official location for binaries of the other plugin projects?
Not yet. It would be nice to publish them on Maven Central too.

We started to work on Plugins CI during last Hackathon [1].
This page is linked under "Plugins" on start Gerrit project page: [2].
The sources can be found here [3].


Bassem Rabil

unread,
Jul 18, 2014, 10:04:18 AM7/18/14
to repo-d...@googlegroups.com, sax...@gmail.com
Here is the URL for Gerrit plugin builds [1] that Luca has setup.

Luca Milanesio

unread,
Jul 18, 2014, 10:09:15 AM7/18/14
to Bassem Rabil, Edwin Kempin, Repo and Gerrit Discussion, sax...@gmail.com
Can we publish the URL from Gerrit home page ?

:-)

Luca.

Edwin Kempin

unread,
Jul 18, 2014, 10:16:23 AM7/18/14
to Luca Milanesio, Bassem Rabil, Repo and Gerrit Discussion, Will Saxon
2014-07-18 16:09 GMT+02:00 Luca Milanesio <luca.mi...@gmail.com>:
Can we publish the URL from Gerrit home page ?
I've added it as 'Build Server' in the Ressources section, let me know if you prefer another label.

Luca Milanesio

unread,
Jul 18, 2014, 10:22:05 AM7/18/14
to Edwin Kempin, Bassem Rabil, Repo and Gerrit Discussion, Will Saxon
Sounds good, thanx :-)

Luca.

Will Saxon

unread,
Jul 18, 2014, 11:00:06 AM7/18/14
to repo-d...@googlegroups.com, edwin....@gmail.com, bassem.ra...@ericsson.com, sax...@gmail.com
This is exactly what I wanted, thanks!

Mark Derricutt

unread,
Jul 20, 2014, 4:26:14 PM7/20/14
to Edwin Kempin, Repo and Gerrit Discussion
On 18 Jul 2014, at 23:35, Edwin Kempin wrote:

> The final release for Gerrit version 2.9 is now available.

Congrats!

Luca Milanesio

unread,
Jul 29, 2014, 3:44:18 AM7/29/14
to Will Saxon, Repo and Gerrit Discussion
Hi Will,
at the moment just send a request to repo-discuss and we'll do it for you.

This time I've done it already for you:

In the long run there will be an automatic fetch of Jenkins YAML files from:

You'll then be able to directly send your job request and getting it review and merged.

HTH.

Luca.

On 29 Jul 2014, at 01:07, Will Saxon <sax...@gmail.com> wrote:

Hello Luca,

What is the preferred way to request a new build on your CI server? I wanted to grab the motd plugin but do not see it listed on master. There are a couple of other plugins that look useful also.

Thanks,

-Will

Neil Leathers

unread,
Aug 1, 2014, 3:41:04 PM8/1/14
to repo and gerrit
Could the plugins for gitiles and its-??? be added to the 2.9 CI builds?

Neil Leathers


--

Luca Milanesio

unread,
Aug 1, 2014, 4:37:16 PM8/1/14
to Neil Leathers, repo and gerrit
Unfortunately not :-(

1) Gitiles does not have a stable-2.9 branch and I did not manage to build it on master either (http://ci.gerritforge.com/job/Gitiles_master/) - @Dave any help on that?
2) Its-* do not have any stable-2.9 branch

P.S. Bear in mind that when there is no stable-2.9 branch it means that typically the master version should work.

HTH

Luca.

Dave Borowitz

unread,
Aug 1, 2014, 5:08:27 PM8/1/14
to Luca Milanesio, Neil Leathers, repo and gerrit
On Fri, Aug 1, 2014 at 1:37 PM, Luca Milanesio <luca.mi...@gmail.com> wrote:
Unfortunately not :-(

1) Gitiles does not have a stable-2.9 branch and I did not manage to build it on master either (http://ci.gerritforge.com/job/Gitiles_master/) - @Dave any help on that?
2) Its-* do not have any stable-2.9 branch

P.S. Bear in mind that when there is no stable-2.9 branch it means that typically the master version should work.

So what's the problem? Does the CI build depend on there being a branch named "stable-2.9", can it not build from master?

Luca Milanesio

unread,
Aug 1, 2014, 5:21:48 PM8/1/14
to Dave Borowitz, Neil Leathers, repo and gerrit
Hi Dave,
master builds are already available but Gitiles fails since build#37:

What am I doing wrong ?

a) git clone https://gerrit.googlesource.com/gitiles (with submodules updates)
b) buck build all

The error on CI is:

Building in workspace /home/gitent/ci.gerritforge.com/jobs/Gitiles_master/workspace
Fetching changes from the remote Git repository
Fetching upstream changes from https://gerrit.googlesource.com/gitiles
Checking out Revision c99d0bb23c81d0932d48675f6be363952e7f0b35 (origin/master)
[workspace] $ /bin/sh -xe /tmp/hudson1376008062725639435.sh
+ buck build all
fatal: Not a valid object name bucklets/buckversion
From https://gerrit.googlesource.com/buck
   7a429cc..71b70bb  github-master -> origin/github-master
Buck is at 0fe4569e871fd6588f7cbfb4b1d4a14baa791a9f,
but should be bucklets/buckversion.
Buck is updating itself.
To disable this, add a '.nobuckcheck' file to your project root.
In general, you should only disable this if you are developing Buck.
error: pathspec 'bucklets/buckversion' did not match any file(s) known to git.

Luca.

Dave Borowitz

unread,
Aug 1, 2014, 5:28:28 PM8/1/14
to Luca Milanesio, Neil Leathers, repo and gerrit
git submodule update --init?

Luca Milanesio

unread,
Aug 1, 2014, 5:41:08 PM8/1/14
to Dave Borowitz, Neil Leathers, repo and gerrit
Done already:


... unless Jenkins Git plugin is a liar ;-)

Will try to do it manually to see if that helps.

Luca.

David Pursehouse

unread,
Aug 1, 2014, 5:45:58 PM8/1/14
to Luca Milanesio, Dave Borowitz, repo-discuss, Neil Leathers


On 1 Aug 2014 22:21, "Luca Milanesio" <luca.mi...@gmail.com> wrote:
>
> Hi Dave,
> master builds are already available but Gitiles fails since build#37:
> http://ci.gerritforge.com/job/Gitiles_master/37/
>
> What am I doing wrong ?
>
> a) git clone https://gerrit.googlesource.com/gitiles (with submodules updates)
> b) buck build all
>
> The error on CI is:
>
> Building in workspace /home/gitent/ci.gerritforge.com/jobs/Gitiles_master/workspace
> Fetching changes from the remote Git repository
> Fetching upstream changes from https://gerrit.googlesource.com/gitiles
> Checking out Revision c99d0bb23c81d0932d48675f6be363952e7f0b35 (origin/master)
> [workspace] $ /bin/sh -xe /tmp/hudson1376008062725639435.sh
> + buck build all
> fatal: Not a valid object name bucklets/buckversion
> From https://gerrit.googlesource.com/buck
>    7a429cc..71b70bb  github-master -> origin/github-master
> Buck is at 0fe4569e871fd6588f7cbfb4b1d4a14baa791a9f,
> but should be bucklets/buckversion.
> Buck is updating itself.
> To disable this, add a '.nobuckcheck' file to your project root.
> In general, you should only disable this if you are developing Buck.
> error: pathspec 'bucklets/buckversion' did not match any file(s) known to git.

IIRC you need to symlink the buckversion file from the gerrit project.

Dave Borowitz

unread,
Aug 1, 2014, 5:46:51 PM8/1/14
to Luca Milanesio, Neil Leathers, repo and gerrit
On Fri, Aug 1, 2014 at 2:40 PM, Luca Milanesio <luca.mi...@gmail.com> wrote:
Done already:


... unless Jenkins Git plugin is a liar ;-)

Will try to do it manually to see if that helps.

Luca.

On 1 Aug 2014, at 22:28, Dave Borowitz <dbor...@google.com> wrote:

git submodule update --init?


On Fri, Aug 1, 2014 at 2:21 PM, Luca Milanesio <luca.mi...@gmail.com> wrote:
Hi Dave,
master builds are already available but Gitiles fails since build#37:

What am I doing wrong ?

a) git clone https://gerrit.googlesource.com/gitiles (with submodules updates)
b) buck build all
This sequence of commands works for me.

The error on CI is:


Building in workspace /home/gitent/ci.gerritforge.com/jobs/Gitiles_master/workspace
Fetching changes from the remote Git repository
Fetching upstream changes from https://gerrit.googlesource.com/gitiles
Checking out Revision c99d0bb23c81d0932d48675f6be363952e7f0b35 (origin/master)
[workspace] $ /bin/sh -xe /tmp/hudson1376008062725639435.sh
+ buck build all
fatal: Not a valid object name bucklets/buckversion
From https://gerrit.googlesource.com/buck
   7a429cc..71b70bb  github-master -> origin/github-master
Buck is at 0fe4569e871fd6588f7cbfb4b1d4a14baa791a9f,
but should be bucklets/buckversion.
Buck is updating itself.
To disable this, add a '.nobuckcheck' file to your project root.
In general, you should only disable this if you are developing Buck.
error: pathspec 'bucklets/buckversion' did not match any file(s) known to git.

I don't think you're simply missing the submodule. Clone without recursive now gives you a helpful error when you try to build:
$ buck build all
Using buckd.
Bucklets directory is missing or empty: /usr/local/google/home/dborowitz/w/dvcs/gitiles/bucklets
Run `git submodule update --init`
BUILD FAILED: Parse error for BUCK file ./BUCK: Stream closed

It's almost as if you're trying to build on a filesystem that doesn't support symlinks. ".buckversion" is a symlink to "bucklets/buckversion"; since it's a symlink, the file contents actually read "bucklets/buckversion."

Dave Borowitz

unread,
Aug 1, 2014, 5:48:00 PM8/1/14
to David Pursehouse, Luca Milanesio, repo-discuss, Neil Leathers
No, as I mentioned in my other email, .buckversion is a symlink to bucklets/buckversion. bucklets is a submodule to the bucklets project and provides the version file:

Luca Milanesio

unread,
Aug 1, 2014, 6:13:46 PM8/1/14
to Dave Borowitz, Neil Leathers, repo and gerrit
ah ah ... same problem again :-(

$ git --version
git version 1.7.5.4

The Git version I have on the CI does not support symlinks :-(

Will create the link manually and try again.

Luca.

On 1 Aug 2014, at 22:46, Dave Borowitz <dbor...@google.com> wrote:

On Fri, Aug 1, 2014 at 2:40 PM, Luca Milanesio <luca.mi...@gmail.com> wrote:
Done already:

<Screen Shot 2014-08-01 at 22.40.04.png>

Dave Borowitz

unread,
Aug 1, 2014, 6:16:14 PM8/1/14
to Luca Milanesio, Neil Leathers, repo and gerrit
On Fri, Aug 1, 2014 at 3:13 PM, Luca Milanesio <luca.mi...@gmail.com> wrote:
ah ah ... same problem again :-(

$ git --version
git version 1.7.5.4

The Git version I have on the CI does not support symlinks :-(

Huh? git has supported symlinks for ages and ages.

Luca Milanesio

unread,
Aug 1, 2014, 6:18:10 PM8/1/14
to Dave Borowitz, Neil Leathers, repo and gerrit
Ah ... could it be then JGit not supporting symlinks ? Actually I'm using the JGit driver in Jenkins for cloning repos ...

Let me try to move back to the native implementation.

Luca.

Neil Leathers

unread,
Aug 1, 2014, 6:24:18 PM8/1/14
to repo and gerrit


For gitiles there is a stable 2.9 branch. I think it was created due to the compile issues from 2.8, 2.9, and master diverging.

Neil Leathers

Luca Milanesio

unread,
Aug 1, 2014, 6:29:52 PM8/1/14
to Dave Borowitz, Neil Leathers, repo and gerrit
Bingo: it is actually a Jenkins Git-plugin issue:

Hopefully fixed ... let me try to upgrade the Git plugin.

Luca.

Luca Milanesio

unread,
Aug 1, 2014, 6:42:11 PM8/1/14
to Dave Borowitz, Neil Leathers, repo and gerrit
Yep, problem resolved and Gitiles master is green again :-)
Thanks Dave for your help.

@Neil: will create a job for gitiles-plugin stable-2.9 as well.

Luca.

Joe Hansche

unread,
Aug 20, 2014, 11:11:05 AM8/20/14
to repo-d...@googlegroups.com
Now that the tracking_ids table is gone, and the trackingids are only indexed in Lucene, is there a (simple) way to get all tracker ids into the index without using the [trackingids] footers?

We do not use the footers in our commit messages, and would instead prefer that any tracking id that a [commentlink] section (i.e., its-base and friends -- in our case, its-jira) would otherwise recognize as a JIRA issue id should be indexed as a tracking id -- thus enabling the "tr:*" search predicate.  Is this supported?

Prior to 2.9, I was using a python script as a hook that would automatically scan the commit message and update the tracking_ids table in postgres directly, and that worked great.  But now that table is gone, and I don't know how to use the lucene index.

Is there some hidden feature of the its-* plugins that automatically contributes to the trackingids index?  Or is it possible to add the tracking ids into the lucene index so that the "tr:" predicate works again?  This is the main integration point between our JIRA and Gerrit servers [1], and not having the tracking ids indexed now renders that integration unusable.

Any pointers?


On Friday, July 18, 2014 7:35:59 AM UTC-4, Edwin Kempin wrote:
The final release for Gerrit version 2.9 is now available.

Dave Borowitz

unread,
Aug 20, 2014, 11:16:16 AM8/20/14
to Joe Hansche, repo-discuss
On Wed, Aug 20, 2014 at 8:11 AM, Joe Hansche <jhan...@meetme.com> wrote:
Now that the tracking_ids table is gone, and the trackingids are only indexed in Lucene, is there a (simple) way to get all tracker ids into the index without using the [trackingids] footers?

We do not use the footers in our commit messages, and would instead prefer that any tracking id that a [commentlink] section (i.e., its-base and friends -- in our case, its-jira) would otherwise recognize as a JIRA issue id should be indexed as a tracking id -- thus enabling the "tr:*" search predicate.  Is this supported?

Prior to 2.9, I was using a python script as a hook that would automatically scan the commit message and update the tracking_ids table in postgres directly, and that worked great.  But now that table is gone, and I don't know how to use the lucene index.

Sorry, for now, you will have to read the tr terms out of the index:

The DB is not a public API, so we changed it behind your back. Sorry.

I would be totally ok with exposing this list of terms as a public REST API.
 
Is there some hidden feature of the its-* plugins that automatically contributes to the trackingids index?  Or is it possible to add the tracking ids into the lucene index so that the "tr:" predicate works again?

It is already indexed (see above), if it's not working, it's a bug that will need to be fixed on stable.
 
This is the main integration point between our JIRA and Gerrit servers [1], and not having the tracking ids indexed now renders that integration unusable.

Any pointers?


On Friday, July 18, 2014 7:35:59 AM UTC-4, Edwin Kempin wrote:

--

Joe Hansche

unread,
Aug 20, 2014, 11:39:12 AM8/20/14
to repo-d...@googlegroups.com, jhan...@meetme.com


On Wednesday, August 20, 2014 11:16:16 AM UTC-4, Dave Borowitz wrote:
On Wed, Aug 20, 2014 at 8:11 AM, Joe Hansche <jhan...@meetme.com> wrote:
Now that the tracking_ids table is gone, and the trackingids are only indexed in Lucene, is there a (simple) way to get all tracker ids into the index without using the [trackingids] footers?

We do not use the footers in our commit messages, and would instead prefer that any tracking id that a [commentlink] section (i.e., its-base and friends -- in our case, its-jira) would otherwise recognize as a JIRA issue id should be indexed as a tracking id -- thus enabling the "tr:*" search predicate.  Is this supported?

Prior to 2.9, I was using a python script as a hook that would automatically scan the commit message and update the tracking_ids table in postgres directly, and that worked great.  But now that table is gone, and I don't know how to use the lucene index.

Sorry, for now, you will have to read the tr terms out of the index:

The DB is not a public API, so we changed it behind your back. Sorry.

I would be totally ok with exposing this list of terms as a public REST API.

I don't need to read the index itself.  I want to allow the "tr" predicate to find tracking ids that the Gerrit trackingids feature does not find.  It sounds like this should already be using the existing tr terms in the lucene index, correct?  My problem is that the way Gerrit has implemented the trackingids feature, it will *only* index the tracking id if it exists as a footer in the commit message.  

This works:

Some commit message

Change-Id: Iabc1234...
Bug: JIRA-123

This does not:

JIRA-123: Some commit message

Change-Id: Iabc1234...

However, the [commentlink] feature finds the "JIRA-123" and correctly links it to our JIRA server.  Likewise, the its-jira plugin correctly identifies it as a JIRA issue id (and will comment on the JIRA issue if enabled, etc).  The only thing missing now is that I cannot search for that issue id with a search query like:  "tr:JIRA-123"

Are those tracking ids indexed anywhere else, in a way that would allow a search query to find all pending changes that contain that issue id?

Dave Borowitz

unread,
Aug 20, 2014, 11:47:55 AM8/20/14
to Joe Hansche, repo-discuss
On Wed, Aug 20, 2014 at 8:39 AM, Joe Hansche <jhan...@meetme.com> wrote:


On Wednesday, August 20, 2014 11:16:16 AM UTC-4, Dave Borowitz wrote:
On Wed, Aug 20, 2014 at 8:11 AM, Joe Hansche <jhan...@meetme.com> wrote:
Now that the tracking_ids table is gone, and the trackingids are only indexed in Lucene, is there a (simple) way to get all tracker ids into the index without using the [trackingids] footers?

We do not use the footers in our commit messages, and would instead prefer that any tracking id that a [commentlink] section (i.e., its-base and friends -- in our case, its-jira) would otherwise recognize as a JIRA issue id should be indexed as a tracking id -- thus enabling the "tr:*" search predicate.  Is this supported?

Prior to 2.9, I was using a python script as a hook that would automatically scan the commit message and update the tracking_ids table in postgres directly, and that worked great.  But now that table is gone, and I don't know how to use the lucene index.

Sorry, for now, you will have to read the tr terms out of the index:

The DB is not a public API, so we changed it behind your back. Sorry.

I would be totally ok with exposing this list of terms as a public REST API.

I don't need to read the index itself.

Sorry, totally misread what you were trying to do. Thanks for the clarification.
 
I want to allow the "tr" predicate to find tracking ids that the Gerrit trackingids feature does not find.  It sounds like this should already be using the existing tr terms in the lucene index, correct?  My problem is that the way Gerrit has implemented the trackingids feature, it will *only* index the tracking id if it exists as a footer in the commit message.  

Ok, I'm with you here.
 
This works:

Some commit message

Change-Id: Iabc1234...
Bug: JIRA-123

This does not:

JIRA-123: Some commit message

Change-Id: Iabc1234...

However, the [commentlink] feature finds the "JIRA-123" and correctly links it to our JIRA server.  Likewise, the its-jira plugin correctly identifies it as a JIRA issue id (and will comment on the JIRA issue if enabled, etc).  The only thing missing now is that I cannot search for that issue id with a search query like:  "tr:JIRA-123"

Are those tracking ids indexed anywhere else, in a way that would allow a search query to find all pending changes that contain that issue id?

Well, there's always (tr:JIRA-123 OR message:JIRA-123). Except maybe Lucene tokenizes "JIRA-123" as [JIRA] [123] so you'd get false positives. Damn.

I think changing the tr field to respect commentlink is a reasonable idea. The catch is we have no way of reindexing all affected changes when a project-specific commentlink changes.

Joe Hansche

unread,
Aug 20, 2014, 12:00:13 PM8/20/14
to repo-d...@googlegroups.com, jhan...@meetme.com


On Wednesday, August 20, 2014 11:47:55 AM UTC-4, Dave Borowitz wrote:
On Wed, Aug 20, 2014 at 8:39 AM, Joe Hansche <jhan...@meetme.com> wrote:


On Wednesday, August 20, 2014 11:16:16 AM UTC-4, Dave Borowitz wrote:
On Wed, Aug 20, 2014 at 8:11 AM, Joe Hansche <jhan...@meetme.com> wrote:
Now that the tracking_ids table is gone, and the trackingids are only indexed in Lucene, is there a (simple) way to get all tracker ids into the index without using the [trackingids] footers?

We do not use the footers in our commit messages, and would instead prefer that any tracking id that a [commentlink] section (i.e., its-base and friends -- in our case, its-jira) would otherwise recognize as a JIRA issue id should be indexed as a tracking id -- thus enabling the "tr:*" search predicate.  Is this supported?

Prior to 2.9, I was using a python script as a hook that would automatically scan the commit message and update the tracking_ids table in postgres directly, and that worked great.  But now that table is gone, and I don't know how to use the lucene index.

Sorry, for now, you will have to read the tr terms out of the index:

The DB is not a public API, so we changed it behind your back. Sorry.

I would be totally ok with exposing this list of terms as a public REST API.

I don't need to read the index itself.

Sorry, totally misread what you were trying to do. Thanks for the clarification.
 
I want to allow the "tr" predicate to find tracking ids that the Gerrit trackingids feature does not find.  It sounds like this should already be using the existing tr terms in the lucene index, correct?  My problem is that the way Gerrit has implemented the trackingids feature, it will *only* index the tracking id if it exists as a footer in the commit message.  

Ok, I'm with you here.
 


Well, there's always (tr:JIRA-123 OR message:JIRA-123). Except maybe Lucene tokenizes "JIRA-123" as [JIRA] [123] so you'd get false positives. Damn.

Actually, looks like message:JIRA-123 does work correctly (and it's what I used to use when I was starting this plugin -- I only abandoned it in favor of "tr" because "message" was very slow).  But as of now, the "message" predicate uses the lucene index, doesn't it?  So that should be much faster now.  I'll try updating the plugin to use that and see if it impacts performance.  Obviously the tr index would be preferable, since it would be a lot smaller than the full-text "message" index.
 

I think changing the tr field to respect commentlink is a reasonable idea. The catch is we have no way of reindexing all affected changes when a project-specific commentlink changes.

I think the same is true even if the [trackingids] config changes, isn't it?

Dave Borowitz

unread,
Aug 20, 2014, 12:05:38 PM8/20/14
to Joe Hansche, repo-discuss
On Wed, Aug 20, 2014 at 9:00 AM, Joe Hansche <jhan...@meetme.com> wrote:


On Wednesday, August 20, 2014 11:47:55 AM UTC-4, Dave Borowitz wrote:



On Wed, Aug 20, 2014 at 8:39 AM, Joe Hansche <jhan...@meetme.com> wrote:


On Wednesday, August 20, 2014 11:16:16 AM UTC-4, Dave Borowitz wrote:
On Wed, Aug 20, 2014 at 8:11 AM, Joe Hansche <jhan...@meetme.com> wrote:
Now that the tracking_ids table is gone, and the trackingids are only indexed in Lucene, is there a (simple) way to get all tracker ids into the index without using the [trackingids] footers?

We do not use the footers in our commit messages, and would instead prefer that any tracking id that a [commentlink] section (i.e., its-base and friends -- in our case, its-jira) would otherwise recognize as a JIRA issue id should be indexed as a tracking id -- thus enabling the "tr:*" search predicate.  Is this supported?

Prior to 2.9, I was using a python script as a hook that would automatically scan the commit message and update the tracking_ids table in postgres directly, and that worked great.  But now that table is gone, and I don't know how to use the lucene index.

Sorry, for now, you will have to read the tr terms out of the index:

The DB is not a public API, so we changed it behind your back. Sorry.

I would be totally ok with exposing this list of terms as a public REST API.

I don't need to read the index itself.

Sorry, totally misread what you were trying to do. Thanks for the clarification.
 
I want to allow the "tr" predicate to find tracking ids that the Gerrit trackingids feature does not find.  It sounds like this should already be using the existing tr terms in the lucene index, correct?  My problem is that the way Gerrit has implemented the trackingids feature, it will *only* index the tracking id if it exists as a footer in the commit message.  

Ok, I'm with you here.
 


Well, there's always (tr:JIRA-123 OR message:JIRA-123). Except maybe Lucene tokenizes "JIRA-123" as [JIRA] [123] so you'd get false positives. Damn.

Actually, looks like message:JIRA-123 does work correctly (and it's what I used to use when I was starting this plugin -- I only abandoned it in favor of "tr" because "message" was very slow).  But as of now, the "message" predicate uses the lucene index, doesn't it?  So that should be much faster now.

Yep :)

Please do let me know if you run into false positives.
 
I'll try updating the plugin to use that and see if it impacts performance.  Obviously the tr index would be preferable, since it would be a lot smaller than the full-text "message" index.
 

I think changing the tr field to respect commentlink is a reasonable idea. The catch is we have no way of reindexing all affected changes when a project-specific commentlink changes.

I think the same is true even if the [trackingids] config changes, isn't it?

Yes. The difference is that trackingids are in gerrit.config whereas of 2.7 or so[1] commentlinks can be enabled/disabled per project in a running server. If you update trackingids while your server is down, you can reindex the whole thing before bringing it back up. If someone who is not a server admin pushes to refs/meta/config in a way that affects commentlinks, you're out of luck.

Yi Zhang

unread,
Aug 26, 2014, 12:05:41 PM8/26/14
to repo-d...@googlegroups.com
Hello Edwin,

One feature in the old GUI that I am really missing is the shortcut "f" to display the file list during code review. It's very handy when you need to jump to a file. Is there any way that you can bring in back? 

Best Regards,

Yi

Motti Strom

unread,
Oct 6, 2014, 6:13:33 AM10/6/14
to repo-d...@googlegroups.com
Just to echo this, the file overview popup via the "f" key shortcut that existed in the old UI was very useful for quickly jumping between specific files.

Any plans to bring it back? Should I file an issue/bug?

Motti

--

Doug Kelly

unread,
Oct 6, 2014, 5:58:12 PM10/6/14
to repo-d...@googlegroups.com, mo...@copycopy.cc


On Monday, October 6, 2014 5:13:33 AM UTC-5, Motti Strom wrote:
Just to echo this, the file overview popup via the "f" key shortcut that existed in the old UI was very useful for quickly jumping between specific files.

Any plans to bring it back? Should I file an issue/bug?

It was reported back in https://code.google.com/p/gerrit/issues/detail?id=2169 and resolved WontFix.  I know several of my colleagues like the feature, though, and would like it back as well -- you're not alone.

Thomas Swindells (tswindel)

unread,
Oct 7, 2014, 4:59:49 AM10/7/14
to Doug Kelly, repo-d...@googlegroups.com, mo...@copycopy.cc

+1 for bringing it back.

I frequently use the f key to check whether another file has been modified. If the other file has been modified I keep reviewing the current file from the place I am at, if it hasn't I add a comment in the current file at the place I am at. Using 'u' is horrendous in this scenario as it loses the position that you are at.

 

Thomas

--

Saša Živkov

unread,
Oct 7, 2014, 6:19:28 AM10/7/14
to Thomas Swindells (tswindel), Doug Kelly, repo-d...@googlegroups.com, mo...@copycopy.cc
On Tue, Oct 7, 2014 at 10:59 AM, Thomas Swindells (tswindel) <tswi...@cisco.com> wrote:

+1 for bringing it back.

I frequently use the f key to check whether another file has been modified. If the other file has been modified I keep reviewing the current file from the place I am at, if it hasn't I add a comment in the current file at the place I am at. Using 'u' is horrendous in this scenario as it loses the position that you are at.

Although I got used to using 'u' I agree that we need a file-select key which works the same as the old 'f' key.
I would also like to point out that the 'f' key is already used by the code-mirror to find the next occurrence of
character in the current line. For example, typing fx will position the cursor to the next 'x' in that line.
This is the standard vim binding.
We probably need to choose a different file-select key.

Zu, Bruce

unread,
Oct 9, 2014, 3:42:01 AM10/9/14
to Thomas Swindells (tswindel), Doug Kelly, repo-d...@googlegroups.com, mo...@copycopy.cc

+1 for bringing it back.

I cannot leave the old CS only for this feature.

men...@gmail.com

unread,
May 2, 2015, 2:40:23 AM5/2/15
to repo-d...@googlegroups.com, luca.mi...@gmail.com, neil.r....@gmail.com
It's not ok for me,how can  i  fix it? Thanks!

buck build all
tools/gitiles# buck build all
Using buckd.
BUILD FAILED: No build file at all/BUCK when resolving target //all:all.


在 2014年8月2日星期六 UTC+8上午5:46:51，Dave Borowitz写道：


Luca.

HTH

Luca.


-- 
-- 
To unsubscribe, email repo-discuss+unsub...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


-- 
-- 
To unsubscribe, email repo-discuss+unsub...@googlegroups.com

More info at http://groups.google.com/group/repo-discuss?hl=en

--- 
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


-- 
-- 
To unsubscribe, email repo-discuss+unsub...@googlegroups.com

David Ostrovsky

unread,
May 4, 2015, 6:29:47 AM5/4/15
to repo-d...@googlegroups.com

Am Samstag, 2. Mai 2015 08:40:23 UTC+2 schrieb Guangyi Meng:
It's not ok for me,how can  i  fix it? Thanks!

buck build all
tools/gitiles# buck build all

This is wrong command to build plugin in Gerrit tree mode. Here
is the description: [1]. Check "Build in Gerrit tree section".


Reply all
Reply to author
Forward
0 new messages