gerrit

gerrit以及repo的用户使用

匿名 (未验证) 提交于 2019-12-03 00:25:02
1.服务器开通Gerrit账号密码 2.登录Gerrit服务器,设置邮箱以及用户名 3.设置sshKey到Gerrit服务器上 4.测试本地是否能连上Gerrit服务器 ssh -p port username@192.168.120.246 5.本地下载安装git 6.本地下载安装repo,服务器有repo可以用的话,就直接用git clone一个repo工程。 7.修改repo权限 chmod a+x ~/bin/git-repo/repo 8.配置git用户和邮箱 9.可以用repo开始下载代码了 文章来源: gerrit以及repo的用户使用

关于refs/for/ 和refs/heads/

匿名 (未验证) 提交于 2019-12-02 23:43:01
https://www.cnblogs.com/onelikeone/p/6857932.html 1. 这个不是git的规则,而是gerrit的规则, 2. Branches, remote-tracking branches, and tags等等都是对commite的引用(reference),引用都以 “refs/……”表示. 比如 remote branch: origin/git_int(=refs/remotes/origin/git_int) , local tag: v2.0(=refs/tags/v2.0) , local branch: git_int(=refs/heads/git_int) … 3. 简单点说,就是refs/for/mybranch需要经过code review之后才可以提交;refs/heads/mybranch不需要code review。 (since you want to directly push into the branch, rather than create code reviews. Pushing to refs/for/* creates code reviews which must be approved and then submitted. Pushing to refs/heads/* bypasses

gerrit refs相关的一些小研究

匿名 (未验证) 提交于 2019-12-02 23:43:01
https://blog.csdn.net/windfromthesouth/article/details/73467849 gerrit 作为 code review使用不算难,然鹅,总有一些内容知其然不知其所以然,这里稍作研究和记录。 1. refs/for 和 refs/heads 向gerrit服务器提交代码命令: $git push origin HEAD:refs/for/mybranch refs/for/mybranch需要经过code review之后才可以提交; refs/heads/mybranch不需要code review。 2.refs/for 和 refs/changes 向 refs/for/<branch-name> 命名空间下推送提交并不会在其中创建引用,而是为新的提交分配一个ID,称为review-id,并为该review-id的访问建立如下格式的引用 refs/changes/nn/<review-id>/m ,其中: review-id是 Gerrit为评审任务顺序而分配的全局唯一的号码。 nn为review-id的后两位数,位数不足用零补齐。即nn为review-id除以100的余数。 m为修订号,该review-id的首次提交修订号为1,如果该修订被打回,重新提交修订号会自增。 Gerrit server上的project

How to change a patchset and push it as a new one?

安稳与你 提交于 2019-12-02 22:58:16
Is it possible to fetch an existing patchset (that has not been merged into my local machine), change and push it as a new Patch Set? Cindy Langdon @Uncletall put all the steps there and the link, the only thing is that you should not delete the changeId and you should do a git commit --amend. I am giving him a +1. It should be like this On Gerrit, go to the review, select "checkout", on the Download field as opposed to "pull", "cherry-pick", or "patch", then copy the command. On the git project paste the copied link from above This will create a detached head, which is a branch with no name

Can Gerrit work in front of Gitlab or is it meant to replace it

不羁岁月 提交于 2019-12-02 20:49:58
I don't think I'm really understanding how Gerrit can fit into my group's existing workflow. Is Gerrit intended to be the central "hub" of code? I have been imagining it as similar to Atlassian's Crucible, which fits in with Atlassian's Stash or Bitbucker. My group currently uses a very active Gitlab installation but the built-in code review facility is lacking, and I absolutely must inspect code from contractors going into the repo. I need a behind-the-firewall solution, and cost is a big consideration. I have heard positive things about Gerrit, but not really an explanation of how it can fit

How to push tag to specific branch in gerrit

 ̄綄美尐妖づ 提交于 2019-12-02 20:47:34
I have a branch called v2.0 in gerrit. Now I want to the current stat of this branch as v2.0.1 . In my local repository I checked out the branch, then added the tag using git tag v2.0.1 Now I'm trying to push that to gerrit, but I'm not sure how. I tried this: $ git push origin v2.0.1 HEAD:refs/heads/v2.0 ! [remote rejected] v2.0.1 -> v2.0 (prohibited by Gerrit) How can I push the tag to gerrit? After some googling, I found the answer: gerrit accepts only annotated tags. It's quite straightforward to create and push an annotated tag: git checkout v2.0 git tag -am "Adding v2.0.1 tag" v2.0.1 git

How does the Gerrit- trigger plugin in Jenkins works?

Deadly 提交于 2019-12-02 19:34:31
I am trying to understand how does the gerrit-trigger in Jenkins works in details? Also, how is the test for the triggered cose is being invoked ? Thanks, The gerrit trigger works like this: It connects to the gerrit server using ssh and uses the gerrit stream-events command It then watches this stream as the data comes in It will try to match the events to triggers that have defined in your projects Potential pit-falls: Jenkins user has improper ssh credentials Jenkins user does not have the stream-events rights How to check: Login as jenkins user ssh -p 29418 jenkins@your.domain.com gerrit

Edit project.config in a Gerrit project

帅比萌擦擦* 提交于 2019-12-02 17:36:27
I want to add a "verified" label to my Gerrit project to allow Jenkins to verify that the code builds and passes its tests and so on. I know I need to add a section to project.config as below: [label "Verified"] function = MaxWithBlock value = -1 Fails value = 0 No score value = +1 Verified However, how do I get to that file to edit it? Inductiveload The project settings are kept in the Git repository for the project. You can edit them by cloning the project from Gerrit, making the change, committing and pushing back to Gerrit. You can do this for any project, but if you want it to be

Commiter email address does not match in IntelliJ even changing it to correct one

安稳与你 提交于 2019-12-02 17:34:58
When I try to push my commits from git repository to gerrit remote repository from Linux environment in IntelliJ idea I get the following error: remote: ERROR: committer email address ***** [K remote: ERROR: does not match your user account.[K Even if I changed the settings to the correct ones for git and gerrit (I can see that at: git config -l from console), it still picks the old "wrong" email. What could be wrong? you need to reconfigure your email $ git config user.email <your email> $ git commit --amend --reset-author git commit --amend updates your last commits You can set the username

Gerrit: combine multiple commits into one “change”

醉酒当歌 提交于 2019-12-02 17:16:58
As a git best practice, one should commit frequently, but to review the code you may need to review a patch consisting of multiple commits at once. Is there a way multiple commits can be reviewed and either merged or rejected at once? Brad No, Gerrit does not currently support batching commits into one review. However, there are a couple other options. At $DAYJOB, my team uses feature branches for larger changes. The smaller commits are reviewed/merged to the feature branch individually, but the feature branch is only merged in once everything is in a good place and all developers are happy.