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#_pr... 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/#%21/linaroorg - http://www.linaro.org/linaro-blog
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.sokolovsky@linaro.org:
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#_pr... 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/#%21/linaroorg - http://www.linaro.org/linaro-blog
-- To unsubscribe, email repo-discuss+unsubscribe@googlegroups.com More info at http://groups.google.com/group/repo-discuss?hl=en
Hello Edwin,
On Tue, 6 Sep 2011 15:52:49 +0200 Edwin Kempin edwin.kempin@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
[]
2011/9/7 Paul Sokolovsky paul.sokolovsky@linaro.org:
Hello Edwin,
On Tue, 6 Sep 2011 15:52:49 +0200 Edwin Kempin edwin.kempin@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.
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
[]
-- Best Regards, Paul
Linaro.org | Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro http://twitter.com/#%21/linaroorg - http://www.linaro.org/linaro-blog