部署 配置 gitlab-ci 进行持续集成

nainc · 2016年01月13日 · 最后由 s101070791 回复于 2017年02月06日 · 15364 次阅读

在日常工作中,我们经常会写一些单元测试来确保程序可以正确执行,但是写完单元测试后常常会面临这些问题:

  • 有一些小改动懒得跑单元测试

  • 别人改动相关代码影响了你的代码逻辑,但他们不知道你写过这些单元测试或者没有跑单元测试的习惯

  • 项目大了,单元测试很多,跑一遍要花很长时间

这时候可以选择进行持续集成

进行持续集成有很多种方式,介绍一下使用 gitlab-ci 进行持续集成的配置方式。

准备

gitlab 版本升级的很快,公司的 gitlab 是在去年 5 月份安装的,当时的版本还是 7.10,现在已然发布到 8.3 了。 建议把 gitlab 升级到 8.0 以上,8.0 以上的版本自动集成了 gitlab-ci 的功能,无需再自己配置一个 gitlab-ci-server 了。google gitlabci 相关的内容很多都是基于 8.0 以上介绍的。并且 gitlab7.12 以上版本支持使用.gitlab-ci.yml 进行 ci 配置,自己搭建 gitlab-ci 的话很容易出现 ci 版本和 gitlab 不一致导致找不到.gitlab-ci.yml 的问题。 升级方式就不详细说了,详见https://about.gitlab.com/update/ 公司之前用的 Omnibus gitlab,升级很方便,直接 yum install 就 ok 了,升级前记得备份数据库。

gitlab 开启 build 功能

gitlab 项目下-》Project-Settings-》Features 里的 Builds 选项勾上-》保存-》完事儿 开启后会发现菜单多了几个功能,打开 runners,里面有 token 和 url,下面配置 runner 时会用到。

配置 ci-runner

  • 首先安装gitlab-ci-multi-runner,之前有一个 runner 是 gitlab-ci-runner,这个 runner 的代码已经不再维护了,不要装错。
  • 安装完成后启动:gitlab-ci-multi-runner start
  • 注册一个新的 runner: gitlab-cimulti-runner register ,提示输入 url 和 token,输入上一步 runners 里的内容就行了,runner 的名字随便输入。然后提示选择 executer,个人选的 shell,还可以选择 docker 和 ssh
  • 完成后刷新 gitlab 的 runner 页面,可以看到刚才注册的 runner

配置 gitlab-workhouse

之前公司没有使用 gitlab 内置的 nginx,而是自己起的 nginx 做配置。这种情况可能导致 build 的时候 git clone 不下代码,会报这个错误: fatal: reference is not a tree google 了一下,建议的解决办法就是使用 gitlab 内置的一个 gitlab_git_http_server,好像是 8.2 之后的版本改名成了 gitlab-workhouse。 /etc/gitlab/gitlab.rb 中增加配置:

gitlab_workhorse['listen_network'] = "tcp"
gitlab_workhorse['listen_addr'] = "127.0.0.1:8181"

nginx 增加配置:

upstream gitlab_repo {
   server 127.0.0.1:8181 fail_timeout=0;
   server 127.0.0.1:8181 fail_timeout=0;
}
#gitlab的server配置中增加
location ~* \.(git) {
      proxy_read_timeout      300;
      proxy_connect_timeout   300;
      proxy_redirect          off;

      proxy_set_header   Host              $http_host;
      proxy_set_header   X-Forwarded-For   $proxy_add_x_forwarded_for;
      proxy_pass http://gitlab_repo;
  }

###.gitlab-ci.yml 配置 在项目的根目录下创建.gitlab-ci.yml,下面是跑单元测试的配置,当然还可以干很多别的。

before_script:
    - cp config/database.yml.sample config/database.yml
    - bundle install --path vendor/bundle --without development
    - "bundle exec rake db:create RAILS_ENV=test"
    - "bundle exec rake db:migrate RAILS_ENV=test"
  job1:
    script: 'RAILS_ENV=test rake test:units' 

进阶配置请参考文档

到此配置完成,从此之后每一个 push 都会触发 ci 进行 build,提交 Merge quest 后也会有相关 build 结果提示,再也不用担心小伙伴们忘跑单元测试了。

##TODO 其实不需要每个 push 都触发 build 的,希望只在提交 MR 后触发一次 build,在和代码之前看到 build 结果就可以了。还在研究,希望有了解的同学能指点一下。

绝对不是拆 gitlab 的台, = 3= 当时看了 CI 的文档就觉得好复杂,然后就毅然决然的投入了 Jenkins 的怀抱…… 术业专攻,CI 方面用 Jenkins+ 一堆插件 + 一堆 docker 的 slave 真的是好爽…… 在 Gitlab8.0 之后 Jenkins 也有插件可以利用 gitlab 新的 CI Feature 去更新 build result,其实也是很不错的选择

如果不是体验的话, 建议是直接用 jenkins 好了一些的, 整合好,插件强

@williamherry 快来指点一下如何在提交 MR 之后触发一次 build

before_script:
  - gem install bundler --conservative
  - bundle check || bundle install

rspec:
  script: bundle exec rspec
  only:
    - branches
  allow_failure: true

deploy:
  script: 
    - bundle exec cap staging deploy
  only:
    - master
  allow_failure: false

加个 only 就不用每次 push 都同时跑两个 job。

#4 楼 @zhangsm 这个 only: branches 只 build feature 分支吧,不加的话也只跑一个 job 啊

#1 楼 @akirapanda 貌似 gitlab 只有 enterprise 版本才有 jenkins 插件吧

#6 楼 @alucardpj jenkins 有 gitlab 的插件,基本流程是事件后触发钩子,jenkins 负责构筑,然后 jenkins 会在 mr 的评论区新增一条评论,并且修改 build result 的信号灯。但是所有 ci 信息都需要去 jenkins 去看,gitlab 的 ci build 是看不到的,这是缺点。

近期也为公司搭建了一套代码管理和 ci 环境,使用的 gitlab+gitlab-ci+docker。 gitlab-ci 只要有任何提交动作都会触发 ci。但是如果想指定某次不执行 ci,只需要在 commit 信息中加入: [skip ci] 或者 [ci skip] 即可。记得带中括号。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号