Gerrit refs regexp patterns don't work - usefully or at all

[Paul Sokolovsky]

Hello,

We're elaborating our Linaro Gerrit (2.2.1) set up, and would like to
enforce separation between upstream and "our" branches, to disallow
stray commits to upstream branches and keep them pullable from AOSP.
So, we'd like to limit review requests, pushes, etc. to
"refs/heads/for/linaro*" and "refs/heads/linaro*".

Trying to enter exactly that into refs entries for All Project's ACL
lead to "Invalid Name" error. After looking at Gerrit's source, it
turns out that Gerrit expects *-using pattern to end with "/*". Well,
why? Yes, it's nice idea to use hierarchical-like branch names.
Sometimes. But there're also good reasons to restrict branch name to
generic "identifier". For example, to keep one-to-one mapping with
filenames (confined to some dirs), or database names (both useful for
CI for example). So, requiring slash present before "*" seems like
arbitrary restrictions.

Anyway, I wasn't too upset, knowing that arbitrary patterns can be
encoded using regexps, and that's where real surprises start. First of
all, looking at example regexps at
http://gerrit.googlecode.com/svn/documentation/2.2.1/access-control.html#_project_access_control_lists
there were suspiciously stray backslashes in pattern examples. Anyway,
I tried to input "^refs/heads/linaro.*", it was rejected with "Invalid
Name" error. Same for "^refs/heads/linaro.*". Then I just tried example
from the doc, both as is and with slashes stripped -
"\^refs/heads/[a-z]\{1,8\}" & "^refs/heads/[a-z]{1,8}". Same error.

Looking at the source, validation for regexp case is complicated (and
nothing points to backslashes being required): it seems to generate a
subject string which would match entered pattern, and test that simple
for being good refs syntax. Well, I thought, maybe UI validation
outslies itself, and commit changes directly to project.config of
refs/meta/config branch of All-Project. No avail. With config like:

[access "^refs/for/refs/linaro.*"]
push = group Registered Users

it's not possible to submit review against any branch at all.

Thinking here would be that may be regexp library is not available, or
regexp syntax is not enabled by some option, but just searching reviews
with queries like below works just ok:

"project:^platform/buil. status:open"
"project:^platform/buil.* status:open"
"project:^platform/buil.+ status:open"

So, I'm stumbled here - what could be wrong, and where to look next?

Thanks,
Paul

Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

[Edwin Kempin]

Hi Paul,

I'm afraid that regular expressions are broken in Gerrit 2.2.1, see
issue 1015 [1]. It was fixed with commit
9161c709eefc0828a8af4d46f6e8409c307aea1e for Gerrit 2.2.2
The correct syntax for your case would be "^refs/heads/linaro.*". This
syntax is accepted by Gerrit 2.1.8 and current Gerrit master state,
which will be Gerrit 2.2.2.

You are right, that the backslashes in the examples are incorrect and
the documentation needs to be fixed (I can do this as soon as the
Android Gerrit server is back). The backslashes in the documentation
occured due to an incompatible upgrade of args4j. The old version of
args4j required certain characters to be escaped with a backslash.
When we upgraded to the new args4j version all those backslashes that
were used for escaping suddenly became visible...

Best regards,
Edwin

[1] http://code.google.com/p/gerrit/issues/detail?id=1015

2011/9/6 Paul Sokolovsky <paul.so...@linaro.org>:

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

[Magnus Bäck]

On Tuesday, September 06, 2011 at 15:52 CEST,
Edwin Kempin <edwin....@gmail.com> wrote:

[...]

> You are right, that the backslashes in the examples are incorrect and
> the documentation needs to be fixed (I can do this as soon as the
> Android Gerrit server is back). The backslashes in the documentation
> occured due to an incompatible upgrade of args4j. The old version of
> args4j required certain characters to be escaped with a backslash.
> When we upgraded to the new args4j version all those backslashes that
> were used for escaping suddenly became visible...

ITYM asciidoc.

--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson

[Edwin Kempin]

Ups, I've meant asciidoc, not args4j. Sorry for that!

2011/9/6 Magnus Bäck <magnu...@sonyericsson.com>:

[Paul Sokolovsky]

Hello Edwin,

On Tue, 6 Sep 2011 15:52:49 +0200
Edwin Kempin <edwin....@gmail.com> wrote:

> Hi Paul,
>
> I'm afraid that regular expressions are broken in Gerrit 2.2.1, see
> issue 1015 [1]. It was fixed with commit
> 9161c709eefc0828a8af4d46f6e8409c307aea1e for Gerrit 2.2.2
> The correct syntax for your case would be "^refs/heads/linaro.*". This
> syntax is accepted by Gerrit 2.1.8 and current Gerrit master state,
> which will be Gerrit 2.2.2.

Thanks for confirming this issue and providingthe bug reference, Edwin
- I tried to search about these issues, saw people raising questions
about "/*", but somehow didn't see any reports of regexp problems.

I understand that right now is probably not the best time to ask for
this, but assuming that AOSP infrastructure is fully back up, is a new
Gerrit release somewhere in the near queue?

>
> You are right, that the backslashes in the examples are incorrect and
> the documentation needs to be fixed (I can do this as soon as the
> Android Gerrit server is back). The backslashes in the documentation
> occured due to an incompatible upgrade of args4j. The old version of
> args4j required certain characters to be escaped with a backslash.
> When we upgraded to the new args4j version all those backslashes that
> were used for escaping suddenly became visible...
>
> Best regards,
> Edwin
>
> [1] http://code.google.com/p/gerrit/issues/detail?id=1015
>

[]

--
Best Regards,

[Edwin Kempin]

2011/9/7 Paul Sokolovsky <paul.so...@linaro.org>:

> Hello Edwin,
>
> On Tue, 6 Sep 2011 15:52:49 +0200
> Edwin Kempin <edwin....@gmail.com> wrote:
>
>> Hi Paul,
>>
>> I'm afraid that regular expressions are broken in Gerrit 2.2.1, see
>> issue 1015 [1]. It was fixed with commit
>> 9161c709eefc0828a8af4d46f6e8409c307aea1e for Gerrit 2.2.2
>> The correct syntax for your case would be "^refs/heads/linaro.*". This
>> syntax is accepted by Gerrit 2.1.8 and current Gerrit master state,
>> which will be Gerrit 2.2.2.
>
> Thanks for confirming this issue and providingthe  bug reference, Edwin
> - I tried to search about these issues, saw people raising questions
> about "/*", but somehow didn't see any reports of regexp problems.
>
> I understand that right now is probably not the best time to ask for
> this, but assuming that AOSP infrastructure is fully back up, is a new
> Gerrit release somewhere in the near queue?

Shawn has to answer this. I'm not aware of any concrete date for the
next Gerrit release.