赞
踩
gerrit权限控制
原网址:http://blog.csdn.net/chenjh213/article/details/50571190
Gerrit 代码审查权限说明:http://mp.blog.csdn.net/postedit/79251109
Gerrit 服务器自身权限说明:http://mp.blog.csdn.net/postedit/79251112
在Gerrit系统自带下面的群组
所有用户都是匿名用户成员, 所有用户都能继承Anonymous Users所有访问权限.
当前只有Read access权限值得赋予给Anonymous Users群组, 因为其他权限都需要认证.
Project Owners的访问权限在Project范围内有效
Change Owner的访问权限在Change范围内有效
所有在页面上登录成功的用户都会自动注册为gerrit用户,属于Registered Users群组
Registered Users群组通常被赋予Code-Review -1..+1权限, 允许给需要审查代码投票, 但不会引起审查被批准和拒绝
system groups在Gerrit系统内部就定义好了, 而普通群组信息被保存在ACCOUNT_GROUPS表中,Predefined groups群组信息也保存在ACCOUNT_GROUPS表中. Predefined groups群组在Gerrit初始化时创建并且拥有唯一的UUID值 All-Projects -> meta/config -> groups文件内容
# UUID Group Name
#
5210215f92225c45a5ad123016c8706336f55a7d Administrators
df9b717d413c614cb51e39525619b311f077ec15 Non-Interactive Users
global:Anonymous-Users Anonymous Users
global:Project-Owners Project Owners
global:Registered-Users Registered Users
Gerrit自带两个predefined groups:
Administrators
Non-Interactive Users
Administrators是Gerrit root角色, 在Gerrit初始化时Administrate Server权限被赋予给这个Predefined Groups群组.
在Administrators组的成员可以管理所有项目, 但是不意味着任何其他权限. Administrators组不会自动获得代码审查批准和提交权限.
Interactive Users比如在web页面上审查代码, 在提交/获取代码的用户
Non-Interactive Users是可以通过Gerrit接口进行操作的组, 在Gerrit初始化时Priority BATCH和Stream Events权限被赋予给这个Predefined Groups组.
Non-Interactive Users和Interactive Users使用不同的线程池, 防止交互式用户抢占线程. 当系统资源紧张时确保了交互式的用户可以继续工作.
在All Projects项目中的访问权限会自动被其他项目继承, 只有Administrate Server capability能够编辑All-Projects权限.
先计算子项目的访问权限, 再计算All Projects的访问权限, 允许一些权限可以被覆盖.
对一个群组赋予DENY限制时, 通常只对READ权限有效.
refs/heads/*和refs/tags/*是Git常用的引用命名空间, 一个用来存储分支一个用来标签
在refs/*命名空间下的引用都是有效的,Gerrit在refs/*有一些特殊用处的命名空间和引用
这些特殊的引用的内容由Gerrit生成或者包含重要的项目配置信息
refs/changes/* #用于存储审查的补丁
#获取某个补丁集需要审查序号和补丁集序号
#'refs/changes/'<last two digits of change number>/ <change number>/ <patch set number>
refs/meta/config #项目配置的分支
refs/meta/dashboards/* #
refs/notes/review #保存代码审查信息的分支
代码审查时允许用户丢弃这个审查。如果对change有push权限,同时具有push,abandon,restore权限
查看提交中Author和Committer
git log --format=full
commit 2dfae738781a3ba641ee06c913fd51162335a941
Author: admin <c2290910211@163.com>
Commit: gerrit_test <c2290910211@aliyun.com>
admin gerrit_test
Change-Id: I0830cf061306101e977f9adf55270c9b3a3f59c4
允许修改项目以下配置:
子命名空间的所有权可以通过命名空间格式来委派. 要委派以qa/开始的所有分支权限给QA群组,给refs/heads/qa/*添加Owner权限。 QA小组的成员可以进一步细分访问权限,但只能对refs/heads/qa/开始的分支有效.
这类分支控制用户如何上传提交到Gerrit. 根据命名空间赋予的Push权限, 可以允许绕过代码审查直接推送到分支, 也可以允许创建新的change进行代码审查.
在Direct Push权限下,任何已经存在的分支都接收fast-forward提交,创建新的分支需要Create Reference权限. 删除已经存在的分支会被拒绝,因为在这个最安全的模式下, 提交不会被丢弃.
允许分支被删除. 由于force push实际上删除分支后会创建这个分支,但是这是个原子操作并且会被记录,也允许force push更新分支. 带有force选项会导致项目历史中的提交被丢弃.
force选项对只想使用Gerrit访问权限功能而不需要代码审查的项目有效, 对于需要进行代码审查的项目不应该分配这个权限.
Upload To Code Review权限授权在refs/for/refs/heads/BRANCH命名空间上,允许用户上传non-merge提交到refs/for/BRANCH命名空间,创建新的change进行代码审查.
用户在自己环境下提交代码需要clone/fetch项目代码,所以必须赋予Read权限
对于开源公开的Gerrit安装方式,All-Projects中refs/for/refs/heads/*通常给Registered Users赋予Read和Push权限. 很多私有安装, 通常refs/for/refs/heads/*通常给all users简单的赋予Read和Push权限.
force选项赋予refs/for/refs/heads/*命名空间没有作用.
Push Merge Commits权限允许用户上传merge commits.这是Push附加的访问权限,所以只赋予Push Merge Commits权限是不够的. 一些项目希望只能由Gerrit自动合并提交, 可以通过只赋予Push权限而不赋予Push Merge Commit权限.
赋予Push Merge Commit权限通常必须以refs/for/为前缀,例如refs/for/refs/heads/BRANCH. refs/heads/BRANCH作为补充, 赋予Read权限后允许直接推送non-merge提交,赋予Push Merge Commit权限后也允许直接提交一个merge提交.
允许推送带注释的标签到远程仓库, 标签必须带有注释.
#创建带注释的标签 git tag -a <tagname> -m <comment>标签的email一定会与提交者的邮箱进行验证,如果推送其他人的标签需要同时赋予Push Annotated Tag和Forge Committer Identity权限.
git show v1.0允许推送PGP签证的标签到远程仓库
git tag -u "gpg-key-id" -m "tag comment" <tagname>
Read权限控制查看项目的change,comment,code diff和通过SSH或者HTTP协议访问仓库的权限
这个权限非常特殊, 先计算项目中的Read权限, 再计算all-projects的Read权限.
如果项目中赋予DENY Read权限,all-projects项目不管是否赋予ALLOW READ都将无效.这个权限对于隐藏一些项目非常有用.
允许用户在web页面上进行rebase changes, change作者和提交者可以通过页面进行rebase changes(尽管没有赋予Rebase权限)
允许用户从审查者列表中移除其他用户.
Change owners能够移除那些审查分数为0或者负数的审查者.(尽管没有赋予Remove Reviewer权限)
Project owners和site administrators能够移除任何审查者(尽管没有赋予Remove Reviewer权限)
其他用户只能将他们自己从审查者列表中移除.
在项目中配置label My-Name,label My-Name和定义好的范围分数相关联. 同时也关联labelAs-My-Name权限, 可以允许编辑用户定义的label.
Gerrit带有配置好的Code-Review标签
[access "refs/heads/*"]
label-Code-Review = -2..+2 group Administrators
label-Code-Review = -2..+2 group Project Owners
label-Code-Review = -1..+1 group Registered Users
[label "Code-Review"]
function = MaxWithBlock
defaultValue = 0
copyMinScore = true
copyAllScoresOnTrivialRebase = true
value = -2 This shall not be merged
value = -1 I would prefer this is not merged as is
value = 0 No score
value = +1 Looks good to me, but someone else must approve
value = +2 Looks good to me, approved
允许用户提交审查通过的提交. 提交审查代码后会合并到对应的分支上.
Code-Review标签+2是通过,-2是否定, -1~+1只是代表意见并不会影响投票, 审查被通过至少需要一个+2投票并且没有-2投票. 两个+1并不会等于+2
允许用户查看其他人提交的draft changes.
draft changes作者和添加为审查者都能看见draft changes(尽管没有赋予View Drafts权限)
允许用户公开其他人提交的draft changes.
draft changes作者可以公开draft changes(尽管没有赋予Publish Drafts权限)
允许用户删除其他人提交的draft changes.
draft changes作者可以删除draft changes(尽管没有赋予Delete Drafts权限)
允许修改change的主题topic
change owner, branch owners, project owners, and site administrators可以修改主题(尽管没有赋予Edit Topic Name权限)
通过赋予一个群组Owner访问权限在refs/*命名空间, Gerrit管理员可以委派这个项目的访问控制权限给这个群组.
如果需要没有一个人能更新或者删除标签, 连项目owners都没有权限. ALLOW和DENY规则并不能达到这样的目的, 因为项目owners可以赋予任何他们自己想要的访问权限. 覆盖任何从All-Projects或者其他父项目继承的权限是非常有效的方法.
在父项目中BLOCK权限, 使得就算是子项目owners也不能设置block权限为ALLOW. 尽管这样, 也应该保留owners所有non-blocked权限.
BLOCK规则是全局范围的权限. 子项目不能重载继承的BLOCK规则. 从父项目链表中搜索BLOCK规则, 忽略在访问区域中的独占(Exclusive)标志.
push权限赋予BLOCK规则, push和force push等推送都将被阻塞. force push权限赋予BLOCK规则只有force push被阻塞, 但是如果push权限具有ALLOW规则的话可以进行non-forced提交.
BLOCK也可以赋予label投票范围. 下面的配置可以阻塞group X投+2和-2票,仍然可以投-1 ~ +1的票.
在这个阻塞规则min..max范围的目的是: 阻塞-INFINITE..min和max..INFINITE投票,也意味着-1..+1投票范围不受阻塞影响.
当相同访问区域同时包含BLOCK和ALLOW规则, ALLOW规则会重载BLOCK规则.
[ access "refs/heads/*" ] 如果群组X和群组Y都包含了同一个用户, 这个用户依然能够push到refs/heads/*命名空间.
在同一个项目的同一个访问区域,ALLOW规则才会重载BLOCK规则.在同一个项目不同访问区域和子项目的同一个访问区域, ALLOW规则不会重载BLOCK规则.
在All-Projects中阻塞Anonymous Users组的push权限
[ access "refs/tags/*" ] 由于所有人都是Anonymous Users组成员, 所以可以阻塞所有人.
可能项目owner需要创建tag权限
假设提交到发布分支Release-Process需要更为严格的过程, 假设我们需要确信只有Release Engineers群组可以投票,就算是项目owner权限也不可以投票. 在All-Projects我们定义下面的规则.
[ access "refs/heads/stable*" ]
允许用户通过gsql命令访问数据库, 以及包含代码审查信息的分支refs/notes/review
影响Gerrit中owner和administrator角色. 赋予administrateServer能力能够赋予任何群组访问权限.
Gerrit中有两类线程池用来给INTERACTIVE Users和Non-Interactive Users使用,防止抢占线程.
允许其他用户使用Non-Interactive Users的保留线程池.
获取All-Projects中refs/meta/config分支并修改权限配置
git clone ssh://admin@localhost:29418/All-Projects && scp -p -P 29418 admin@localhost:hooks/commit-msg All-Projects/.git/hooks/
#refs/meta/config 是All-Projects的引用
git fetch origin refs/meta/config:refs/remotes/origin/meta/config
git checkout meta/config
#现在目录下有groups project.config两个文件
#groups文件包含project.config中需要的用户组和对应的UUID
#提交修改
git add .
git commit -m "modify config"
git push origin meta/config:meta/config
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。