Gitlab 概述
- [Omnibus] https://doc.gitlab.cc/omnibus/
- [CE] https://doc.gitlab.cc/ce/
Gitlab 架构
[Doc] https://github.com/gitlabhq/gitlabhq/blob/master/doc/development/architecture.md
nginx
:静态 Web 服务器gitlab-shell
:用于处理 Git 命令和修改 authorized keys 列表gitlab-workhorse
:轻量级的反向代理服务器,它会处理一些大的 HTTP 请求,比如文件上传、文件下载、Git push/pull 和 归档下载。其它请求会反向代理到 GitLab Rails 应用,即反向代理给后端的 unicorn。Unicorn
:Ruby Web Server,托管 GitLab Rails 服务。增加 unicorn 的 workers 数量,可以减少应用的响应时间并提高处理并发请求的能力。对于大部分实例,我们建议使用这样的配置:CPU 核心数 + 1 = unicorn workers 数
Gitaly
:执行 gitlab-shell 和 gitloab-workhorse 的 git 操作,并向 GitLab web 应用程序提供一个 API,以从 git(例如 title, branches, tags, other meta data)获取属性,并获取 blob(例如 diffs,commits,files)postgresql
:使用 PostgreSQL 必须确认 GitLab 使用的数据库安装了 pg_trgm 扩展。 这个扩展需要 PostgreSQL 使用 root 用户在 GitLab 每个数据库里面执行CREATE EXTENSION pg_trgm;
命令redis
:Redis 存储每个客户端的 sessions 和后台任务队列。Redis 需求的存储空间很小, 大约每个用户 25kBsidekiq
:Sidekiq 使用多线程处理后台任务(异步)。 这个进程启动的时候会使用整个 Rails 堆栈(200MB+),但是它会在内存泄漏的情况下增加。 一个用户非常活跃的服务器上(10,000个活跃用户),Sidekiq 进程会占用 1GB+ 的内存。logrotate
:日志文件管理
gitlab-shell 组件
[Doc] (https://gitlab.com/gitlab-org/gitlab-shell/blob/master/README.md)
GitLab Shell 的作用:处理 Git 命令
、修改 authorized keys 列表
。GitLab Shell 不是 Unix shell,也不是 Bash 或 Zsh 的替代品。早期的 gitlab-shell 是实现方式为 gitolite。
当通过 SSH
访问 GitLab Server 时,GitLab Shell 会:
- 限制执行预定义好的Git命令(git push, git pull, git annex)
- 调用 GitLab Rails API,检查用户权限
- 执行 pre-receive 钩子(在 GitLab 企业版中叫做 Git 钩子)
- 执行你请求的动作
- 处理 GitLab 的 post-receive 动作
- 处理自定义的 post-receive 动作
当通过 http(s)
访问 GitLab Server 时,工作流程取决于你是从 Git 仓库拉取(pull)代码,还是向 git 仓库推送(push)代码。
- 如果你是从 Git 仓库 pull 代码,GitLab Rails 应用会全权负责处理用户鉴权和执行 Git 命令的工作
如果你是向 Git 仓库 push 代码,GitLab Rails 应用既不会进行用户鉴权也不会执行 Git 命令,它会把以下工作交由 GitLab Shell 进行处理:
调用GitLab Rails API 检查权限
- 执行pre-receive 钩子
- 执行你请求的动作
- 处理 GitLab 的 post-receive 动作
- 处理自定义的 post-receive 动作
也许你会奇怪在通过 http(s) push 代码的情况下,GitLab Rails应用为什么不在 GitLab Shell之前进行鉴权。这是因为 GitLab Rails 应用没有解析 git push 命令的逻辑。好的方法是将这些解析代码放在一个地方,这个地方就是 GitLab Shell,这样我们就可以在通过 SSH 进行访问时重用这段代码。实际上,GitLab Shell 在执行 git push 命令时根本不会进行权限检查,它是依赖于 pre-receive 钩子进行权限检查的。而当你执行 git pull 命令时,权限检查是在命令执行之前的。对 git pull 命令的权限检查要简单得多,因为你只需要检查一个用户是否可以访问这个仓库就可以了(不需要检查分支权限)。
gitlab-workhorse 组件
- Workhorse 可以处理一些请求,而不涉及 Rails:例如,Javascript 文件和 CSS 文件直接从磁盘载入
- Workhorse 可以修改 Rails 发送的响应:例如,如果你在 Rails 中使用 send_file,那么 gitlab-workhorse 将打开磁盘上的文件,并将其内容作为响应体发送给客户端
- Workhorse 可以在从 Rails 请求权限后接管请求。 例如:处理 git clone 动作
- Workhorse 可以在将请求传递给 Rails 之前对其进行修改。 例如:处理 Git LFS 上传 Workhorse 首先向 Rails 请求权限,然后将请求主体存储在临时文件中,然后它将包含临时文件路径的修改后的请求发送到 Rails
- Workhorse 可以管理 Rails 的长期 WebSocket 连接。 例如:处理环境的终端 websocket
- Workhorse 不连接 Redis 或 Postgresql,只连接到 Rails
- 我们假设所有到达 Workhorse 的请求首先通过一个上游代理,如 NGINX 或 Apache
- Workhorse 不接受 HTTPS 连接
- Workhorse 不清除空闲客户端连接
- 我们假设所有对 Rails 的请求都通过 Workhorse
Gitlab 硬件需求
[Doc] https://doc.gitlab.cc/ce/install/requirements.html
CPU
:2 核心 500 用户,4 核心 2000 用户,8 核心 5000 用户 …Memory
:4G 100 用户,8G 1000 用户,32G 4000 用户 …Swap
:即使你服务器有足够多的 RAM, 也要给服务器至少分配2GB
的交换分区。 因为使用交换分区可以在你的可用内存波动的时候降低 GitLab 出错的几率
Gitlab 高可用
- Active/Acitve(双主架构)
- Active/Passive(主从架构)
Acitve/Acitve
Active/Passive
解决方案
:Corosync + Pacemaker + DRBD,参见 “Cluster 集群序列” 学习笔记。
安装 Gitlab CE
Omnibus
Omnibus GitLab 是集成了 GitLab 及 GitLab 所需的服务、依赖的一键安装包。Omnibus GitLab 源已经针对国内网络环境进行优化,镜像源由 TUNA 提供。
安装依赖包:
添加 GitLab 仓库,并安装到服务器上:
启动 gitlab:
若执行 reconfigure 长时间卡在一个地方,可先执行:
开机自启动:
Docker
[Doc]
- https://gitlab.com/gitlab-org/omnibus-gitlab/tree/master/docker
- https://docs.gitlab.com/omnibus/docker/
Gitlab Environment Variable
[Doc] https://docs.gitlab.com/ce/administration/environment_variables.html
|
|
docker run
|
|
docker-compose.yml
|
|
提示
:将 config、data 等数据文件,使用 -v 映射卷以后,即使删除容器再新建一个容器,数据依然存在。
Upgrade GitLab
安装指定版本的 GitLab:
Gitlab 配置
自 GitLab 7.6 开始的新安装包,Gitlab 已经默认将所有的参数写入到 /etc/gitlab/gitlab.rb
文件中。
gitlab-ctl 命令
Gitlab 使用 gitlab-ctl 命令来重新应用 gitlab.rb 的配置。
deploy-page
:Put up the deploy pagediff-config
:Compare the user configuration with package available configurationremove-accounts
:Delete all users and groups used by this packageupgrade
:Run migrations after a package upgrade
General Commands:
cleanse
:Delete all gitlab data, and start from scratch.help
:Print this help message.reconfigure
:Reconfigure the application.show-config
:Show the configuration that would be generated by reconfigure.uninstall
:Kill all processes and uninstall the process supervisor (data will be preserved).
Service Management Commands:
graceful-kill
:Attempt a graceful stop, then SIGKILL the entire process group.hup
:Send the services a HUP.int
:Send the services an INT.kill
:Send the services a KILL.once
:Start the services if they are down. Do not restart them if they stop.restart
:Stop the services if they are running, then start them again.service-list
:List all the services (enabled services appear with a *.)start
:Start services if they are down, and restart them if they stop.status
:Show the status of all the services.stop
:Stop the services, and do not restart them.tail
:Watch the service logs of all enabled services.term
:Send the services a TERM.
Container Registry Commands:
registry-garbage-collect
:Run Container Registry garbage collection.
Database Commands:
pg-upgrade
:Upgrade the PostgreSQL DB to the latest supported versionrevert-pg-upgrade
:Run this to revert to the previous version of the database
使用外部的 Postgresql 和 Redis
Gitlab 使用 CE v8.17,目前 CE 版本只支持外部的 Postgresql,MySQL 只在 EE 版本中被支持。
修改 gitlab.rb
配置部分,修改完毕后使用 gitlab-ctl reconfigure
命令重新配置 gitlab 即可。
Postgresql
|
|
Redis
|
|
重配置 Gitlab
|
|
配置 SMTP 服务
[Doc] https://doc.gitlab.cc/omnibus/settings/smtp.html
测试邮件:
OmniAuth 认证
GitLab 利用 OmniAuth 允许用户使用 Twitter、GitHub 和其他流行服务来登录 GitLab。
OAUTH 协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是 OAUTH 的授权不会使第三方触及到用户的帐号信息(如用户名与密码),即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权,因此 OAUTH 是安全的。oAuth 是 Open Authorization 的简写。
允许从第三方平台,登陆 GitLab 的 providers 有:
- GitHub
- Bitbucket
- GitLab.com
- Shibboleth
- SAML
- Crowd
- Azure
- Auth0
- Authentiq
- OAuth2Generic
配置 OmniAuth
配置 OmniAuth(默认禁用
) 不会阻止标准的 GitLab 身份验证或 LDAP(如果已配置)继续工作。 用户可以选择使用任何已配置的机制来登录 GitLab。
在配置 OmniAuth providers 之前,有几个全局设置是需要考虑的:
- OmniAuth 默认禁用
allow_single_sign_on
允许您指定要允许自动创建帐户的 providers,默认为false
。 如果为 false 的话,用户必须手动创建用户,否则他们将无法通过 OmniAuth 登录- 如果已启用 LDAP/ActiveDirectory,则可以使用
auto_link_ldap_user
,默认为false
。 启用后,通过 OmniAuth 自动创建的用户也将链接到其 LDAP 条目。 block_auto_created_users
默认为true
。 如果为 true,那么自动创建的用户将被默认阻止,并且必须由管理员解除阻止才能登录。
注意
:
- 如果将 block_auto_created_users 设置为 false,请确保只定义您能够控制的 allow_single_sign_on 下的 providers (如 SAML,Shibboleth,Crowd 或 Google),或将其设置为false,否则互联网上的任何用户都可以成功登录你的 GitLab。
- auto_link_ldap_user 要求 LDAP 和 OmniAuth provider 中用户的 uid 相同。
修改默认的运行用户和组
默认情况下 omnibus-gitLab 使用 git 用户登陆 Git gitlab-shell,Git data 是属主也是 git,网页上生成的 SSH URL 也是 git 用户。 同样的,git 用户组也是 Git data 的属组。
不建议在已经安装好的 gitlab 上修改默认的 user/group,因为这会产生无法预知的副作用。 如果你固执的想要修改默认的 user/group,你可以在 /etc/gitlab/gitlab.rb 文件中添加下面加行配置:
|
|
注意
:如果你在已经安装好的 GitLab 中修改了 user/group,reconfigure
不会修改子目录的属主和属组,你需要手动修改, 并确认新用户可以读写 repositories 和 uploads 目录。
设置使用数字表示的用户和组
omnibus-gitlab 为 GitLab, PostgreSQL, Redis 和 NGINX 创建了运行用户。 你可以在 /etc/gitlab/gitlab.rb 文件中指定这些用户的 uid 和 gid。
|
|
禁用管理用户和组账户的功能
默认情况下,omnibus-gitlab 负责创建用户和组账户,以及更新账户信息。该做法对大多数用户是有意义的, 但在某些环境和需求中,我们需要用其他的软件来管理用户和组账号,比如 LDAP 环境。Omnibus-gitlab 建议在系统上保留 omnibus-gitlab 安装包创建的默认用户和组。
配置项:
默认用户:
默认组:
自定义用户和组:
禁用管理存储目录的功能
默认情况下,omnibus-gitlab 负责创建所有必需的文件夹并赋予目录正确的所有权和权限, 并根据配置文件保持更新。
在某些大型组织架构中,随着项目代码和数量的增加,一些目录会存储大量的数据, 为扩展存储能力这些目录可能就需要挂载到NFS(或者其他共享存储)上。
挂载某些文件系统会拒绝 root 用户自动创建目录, 比如 NFS 需要启用 root_squash(压缩 root 用户权限为普通账号,例如 git) 。 要解决这个问题,omnibus-gitlab 会尝试使用该目录的属主用户来自动创建子目录。
如果你挂载了 /etc/gitlab 目录,你可以禁用 omnibus-gitlab 对该目录的管理功能。修改 /etc/gitlab/gitlab.rb :
如果计划重新挂载 GitLab 所有存储目录到每个独立的挂载点上, 应该完全禁用 omnibus-gitlab 对各个存储目录的管理功能。
为禁止对所有存储目录的管理功能, 修改 /etc/gitlab/gitlab.rb :
omnibus-gitlab 建议保留默认的目录。 如该选项已设置, 将有管理员创建目录并设置正确的权限。启用此设置会阻止 omnibus-gitlab 创建如下目录:
更改默认仓库路径
默认情况下 omnibus-gitlab 将仓库数据存储在 /var/opt/gitlab/git-data
目录下,仓库存放在子目录 repositories
里面。 以可以通过修改 /etc/gitlab/gitlab.rb 的这一行来自定义 git-data 的父目录。
|
|
NFS 配置
Step 1:NFS 服务端,安装 NFS
|
|
Step 2:NFS 服务端,配置 NFS
|
|
|
|
Step 2:NFS 客户端(Gitlab),挂载 NFS
如果 /var/opt/gitlab/git-data 目录已经存在 Git 仓库数据, 你可以用下面的命令把数据迁移到新的位置:
|
|
设置延迟启动
为保证服务质量,我们可以设置让 omnibus-gitlab 的服务(Nginx, Redis, Unicorn 等)在指定的文件系统挂载成功后再启动,在 /etc/gitlab/gitlab.rb 文件中添加如下内容:
|
|
启用禁用账户验证防护
|
|
禁用用户开放注册
OpenLDAP 集成
|
|
重新加载 gitlab 服务:
Gitlab 登陆:
Gitlab 验证:
启动、停止 GitLab 服务
禁止自启
|
|
开机自启
|
|
启停 Gitlab 服务
|
|
Reply by email
允许用户通过回复预设的邮件来评论 issue 和合并请求
Reply by email 需要一个 IMAP 的电子邮件帐户。 GitLab允许您为此功能使用三种策略:
- using email sub-addressing
- using a dedicated email address
- using a catch-all mailbox
IMAP
POP3 协议允许电子邮件客户端下载服务器上的邮件,但是在客户端的操作(如移动邮件、标记已读等),不会反馈到服务器上,比如通过客户端收取了邮箱中的 3 封邮件并移动到其他文件夹,邮箱服务器上的这些邮件是没有同时被移动的 。
而 IMAP 提供 webmail 与电子邮件客户端之间的双向通信,客户端的操作都会反馈到服务器上,对邮件进行的操作,服务器上的邮件也会做相应的动作。
同时,IMAP 像 POP3 那样提供了方便的邮件下载服务,让用户能进行离线阅读。IMAP 提供的摘要浏览功能可以让你在阅读完所有的邮件到达时间、主题、发件人、大小等信息后才作出是否下载的决定。此外,IMAP 更好地支持了从多个不同设备中随时访问新邮件。
Email sub-addressing
sub-addressing 是一个允行向 user+some_arbitrary_tag@example.com
发送的任何电子邮件发送的电子邮件都将会发送到 user@example.com
的邮箱中,被 Gmail,Google Apps,Yahoo! Mail,Outlook.com 和 iCloud,以及本地运行的 Postfix 邮件服务器等支持。
反向代理后的 Gitlab HTTPS 设置
前端 LB
:启用 HTTPS后端 Gitlab
:配置 gitlab.rb
默认情况下,如果 external_url
包含 https://
,则 NGINX 将自动检测是否使用 SSL。 如果您在反向代理之后运行 GitLab,则需要将下面的设置应用于 gitlab.rb
:
|
|
重新应用配置:
Gitlab 管理
导入用户 Key
Step 1:用户端,生成用户 key(不设置密码)
|
|
Step 2:Gitlab 服务端导入用户 key
右上角 “个人头像” -> “settings” -> “SSH Keys”,添加用户公钥(默认 id_rsa.pub)
Step3:用户端,验证 SSH 连接方式
|
|
导入 GitHub 项目
Gitlab 目前支持如下几种方式的代码导入
导入 GitHub 项目
- 步骤一:GitHub 生成 Token
如下图所示,菜单位置个人 “settings” -> “Persiona access token” 子项。
- 步骤二:Gitlab 导入项目
选择“List You GitHub Repositories”
后,将列出你的账号所允许被访问的 GitHub 的项目,选择“Import”
导入项目。
Deploy Key
Deploy keys allow read-only access to multiple projects with a single SSH key.
This is really useful for cloning repositories to your Continuous Integration (CI) server. By using deploy keys, you don’t have to setup a dummy user account.
If you are a project master or owner, you can add a deploy key in the project settings under the section 'Deploy Keys'
. Press the ‘New Deploy Key’ button and upload a public SSH key. After this, the machine that uses the corresponding private key has read-only access to the project.
You can’t add the same deploy key twice with the ‘New Deploy Key’ option. If you want to add the same key to another project, please enable it in the list that says ‘Deploy keys from projects available to you’. All the deploy keys of all the projects you have access to are available. This project access can happen through being a direct member of the project, or through a group. See def accessible_deploy_keys
in app/models/user.rb
for more information.
Deploy keys can be shared between projects, you just need to add them to each project.
4.4 安装 gitlab-runner
添加源:
安装 runner
Git workflow
[Doc] https://doc.gitlab.cc/ce/workflow/authorization_for_merge_requests.html
Protected branch flow
- With the protected branch flow everybody works within the same GitLab project.
- The project maintainers get Master access and the regular developers get Developer access.
- The maintainers mark the authoritative branches as ‘Protected’.
- The developers push feature branches to the project and create merge requests to have their feature branches reviewed and merged into one of the protected branches.
- Only users with Master access can merge changes into a protected branch.
Forking workflow
With the forking workflow the maintainers get Master access and the regular developers get Reporter access to the authoritative repository, which prohibits them from pushing any changes to it.
Developers create forks of the authoritative project and push their feature branches to their own forks.
To get their changes into master they need to create a merge request across forks.
Gitlab 高可用
NFS 配置
no_root_squash
:NFS 通常 将 root 用户更改为 nobody。 这是一个很好的安全措施,当 NFS 共享将被许多不同的用户访问。 但是,在这种情况下,只有 GitLab 才能使用 NFS 共享,所以它是安全的。 GitLab 需要 no_root_squash 设置,因为我们需要自动管理文件权限。 没有设置,当 Omnibus 软件包尝试更改权限时,您将收到错误。 请注意,GitLab 和其他捆绑组件不以 root 身份运行,而不作为非特权用户运行。no_root_squash 的要求是允许 Omnibus 包根据需要设置文件的所有权和权限
。sync
:强制同步行为。 默认是异步的,在某些情况下,如果在数据同步之前发生故障,可能会导致数据丢失。
|
|
nobootwait
:不要停止启动进程等待此挂载成为可用lookupcache=positive
:告诉 NFS 客户端遵循positive
(积极)的缓存结果,但会使任何negative
( 消极)缓存结果无效。 Negative 缓存结果会导致 Git 出现问题。 具体来说,git push 可能无法在所有 NFS 客户端上统一注册。 Negative 缓存导致客户端 “记住” 之前文件不存在的情况。rsize、wsize
:通过设置更大的数据块大小(以字节为单位)来一次传输,从而加速读取(rsize)和写入(wsize)的 NFS 通信。默认 4096sec=mode
:指定在验证 NFS 连接时要使用的安全性类型,类型有 sys、krb5、krb5i 和 krb5pproto=tcp or udp
:指定 NFS 挂载使用 TCP or UDP 协议hard or soft
:hard
使用硬挂载的方式挂载系统,该值是默认值,重复请求直到 NFS 服务器回应;soft
使用软挂载的方式挂载系统,若 Client 的请求得不到回应,则重新请求并传回错误信息intr
:当你使用 hard 方式挂载时,若加上 intr 这个参数, 则当 RPC 持结连接时,该次的呼叫是可以被中断的(interrupted)retrans
:重传次数noatime
:访问文件时不修改相关文件的 Access Timenodiratime
:不修改目录的 Access Timenoexec
:不允许直接运行文件,即使该文件有 x 权限nodev
:屏蔽字符设备或块设备的属性nosuid
:屏蔽 suid
共享挂载点
使用默认的 Omnibus 配置时,您需要在所有 GitLab 群集节点之间共享 5 个数据位置(如下表所示),不应共享其他位置。
Location | Description | Default configuration |
---|---|---|
/var/opt/gitlab/git-data |
Git repository data. This will account for a large portion of your data | git_data_dirs({"default" => "/var/opt/gitlab/git-data"}) |
/var/opt/gitlab/.ssh |
SSH authorized_keys file and keys used to import repositories from some other Git services |
user['home'] = '/var/opt/gitlab/' |
/var/opt/gitlab/gitlab-rails/uploads |
User uploaded attachments | gitlab_rails['uploads_directory'] = '/var/opt/gitlab/gitlab-rails/uploads' |
/var/opt/gitlab/gitlab-rails/shared |
Build artifacts, GitLab Pages, LFS objects, temp files, etc. If you’re using LFS this may also account for a large portion of your data | gitlab_rails['shared_path'] = '/var/opt/gitlab/gitlab-rails/shared' |
/var/opt/gitlab/gitlab-ci/builds |
GitLab CI build traces | gitlab_ci['builds_directory'] = '/var/opt/gitlab/gitlab-ci/builds' |
节点之间不应该共享其他 GitLab 目录,包含不需要共享的节点特定文件和 GitLab 代码。 要将日志发送到中央位置,请考虑使用远程 syslog。 GitLab Omnibus 软件包 为 UDP 日志传送提供配置。
示例
:
要移动 git 主目录,必须停止所有 GitLab 服务。 运行 gitlab-ctl stop && systemctl stop gitlab-runsvdir
。 然后继续重新配置。
运行 sudo gitlab-ctl reconfigure
以开始使用中央位置。 请注意,如果您有现有数据,则需要手动 copy/rsync 复制数据到这些新位置,然后重新启动 GitLab。
|
|
日志目录
|
|
迁移日志:
Gerrit + Gitlab 整合
Gitlab CE 的代码 Code Review(代码审核) 功能太弱,总结起来,有以下几个方面:
- 没有很严格的权限控制机制,也无法控制到具体的分支权限,基本权限控制可以说只针对版本库而言
- 用户组概念模糊,所有代码库的权限授权动作,都是针对项目组(Group )而言
- 对于有权限的 git push 操作,会直接修改远程托管代码的仓库的
refs/heads/<branch>
分支。另外,其 Code Review 机制也不够健全
在 Gitlab 中,可以设置 Master 为保护分支,那么普通用户可以自己创建分支并提交代码到自己的分支上,没有权限直接 push 到 Master 分支。用户若需要提交自己的代码到 Master 分支,需要发起一个 Merge Request,项目指定的管理人员收到 Merge Request 后, Review 代码后选择是否合并代码。
Gerrit
Gerrit
是 Googel 开发的,托管 Android 代码的开源项目代码审查工具,也是广泛采用的 Code Review 系统。Gerrit 本身不需要依赖任何其它代码管理工具,就可作为一个独立的代码管理平台。
Gerrit 的优势:
- 非常健全的代码审核及权限控制机制
- 对于任何 git push 的操作,可以控制用户提交的代码,不直接 merge 到
refs/heads/<branch>
分支(即直接进入主代码库,包括 master 和其它分支),而是提交到refs/for/<branch>
分支上进入代码审核流程 - 可以设置
多人员
进行代码审核,分为Verified
(核查,-1/+1 权限,普通开发人员协同审核) 和Code Review
(-2/+2 权限,核心开发/项目管理人员,是否允许 Merge 代码) - 代码审核通过后,项目管理人员可以无需自己合并代码,Gerrit 会主动邮件通知代码提交人员,做最后的 merge 代码到主代码库的动作
- 内置实时复制插件:Merge 代码主动触发复制功能,可以做到具体某一分支或整个代码库的镜像
通过将 Gitlab 和 Gerrit 的集成,除了让 Gerrit 作为 Gitlab 的备份外,借助于 Gerrit 的复制功能,也可以使 Gitlab 作为 Gerrit 的备份,且代码完全是实时同步的。
Gerrit 代码审核工作流:
Gerrit 具体部署,请参见 Git 权威指南 - 学习笔记。
GitLab runner
Runner 类型
GitLab-Runner 可以分类两种类型:Shared Runner(共享型)和Specific Runner(指定型)
Shared Runner
:这种Runner(工人)是所有工程都能够用的。只有系统管理员能够创建Shared Runner。Specific Runner
:这种Runner(工人)只能为指定的工程服务。拥有该工程访问权限的人都能够为该工程创建Shared Runner。
运行 Runner
添加源
Debian / Ubuntu:
RHEL / CentOS:
安装 Gitlab Runner
|
|
注册 Gitlab Runner
|
|