且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

Gerrit - Gitlab集成

更新时间:2023-02-08 14:01:37

通过复制功能在gitlab前使用gerrit。复制功能不会执行git clone / fetch,它只会将(批准的)更改推送到远程存储库。




  • 必须导入存储库通过例如'git push origin master'需要额外的权限(或者你需要成为admin)。除非您忘记删除这些
    权限,否则这不是什么大问题。如果您忘记删除这些权限,或者是
    管理员(拥有这些权限):默认的git push会使
    无需审核。

  • 你必须确保没有人可以提交给gitlab实例。
    否则你很有可能遇到合并冲突(gerrit是
    ,不知道这些新的提交)。您可以保护
    gitlab中的分支机构 - 但管理员(如果我记得正确的话还有
    版本库创建者/所有者)也将始终拥有此权限。

  • 您必须授予gerrit用户主权限,以允许它推送到gitlab存储库。

  • 所有项目必须先在gitlab中创建,否则它们将不会同步(除非您找到一种方法,回购将在gitlab中自动在第一个git push中创建)


In order to improve the development process, our organization have decided to introduce Gerrit in the development workflow. I am the person responsible for implementing Gerrit server. The user guides available in internet were very helpful in implementing Gerrit to our existing workflow. We are using Jenkins and Sonar as Non-interactive users for verifying the builds. But while dealing with repositories one question rises. Most of the open sources are using gerrit-replication plugin to replicate the latest code to their public code repository. These public repositories are exposed using GitLab so that the users can clone the code. Here we doesn't need a public repository as the code is maintained in house.

Is it a good choice to point both GitLab and Gerrit to a common git repository location?

Any help appreciated.

You can use gerrit in front of gitlab via the replication feature. The replication feature does not do a git clone/fetch, it only pushs (approved) changes to a remote repository.

  • you have to import repositories via e.g. 'git push origin master' which requires extra permissions (or you need to be the admin). That is not a big deal unless you forget to remove these permissions. If you forget to remove these permissions or are administrator (who has these permissions): a default "git push" will make it through without being reviewed.
  • you have to make sure that no one can commit to the gitlab instance. Else you have a high chance to run into merge conflicts (gerrit is not aware of these new commits). You can protect the branches in gitlab -- but the admins (and if I remember correct also the repository creator/owner) will always have this right, too.
  • You have to grant a gerrit user master permissions to allow it push to the gitlab repository.
  • All projects have to be first created in gitlab, else they will not be synchronized (unless you find a way that the repo will be automatically created in gitlab on the first git push)