持续集成由以下环节组成：

1. 代码版本库 (gitlab等)
2. CI服务 (gitlab-ci/jenkins等 coordinator)
3. CI Runner

当开发者将修改推送到版本库时，版本库会通知 CI服务，CI服务则会取出一份代码，交给 Runner进行检测，Runner将检测结果汇报给 CI服力。当然，开发者在提交代码之前，应该已经在自己的环境里做过必要的测试了。

Meteor已经选定 Velocity做为官方测试框架，通过 meteor run --test可以调用不同的测试工具完成单元测试到集成测试的各种测试，自带 reporter，同时也考虑了对 CI服务的支持。

例如https://github.com/dcsan/velo-ci是对接 Travis CI服务的示例，主要工作就是写了个 .trivis.yml放在项目根目录下，这样<通过还不清楚的机制>，meteor run --test 运行测试时会将测试结果汇报给 Trivis服务器。Trivis是 github.com提供的配套云端CI服务，对于开源项目免费，商业项目收费。

使用 Gitlab搭建内部的代码库通常是出于价格、网络速度、私有性方面的考虑，因此再搭建一个内部的CI服务也就顺理成章了。不过，其实合理设置内部的 Runner 服务器，使用公有 CI服务也是可行的。

服务器有很多选择。Gitlab是比较流行的仿 github 代码服务，它从2013年开始提供配套的 Gitlab-CI，这个CI还比较新，因此功能相对简单一点，界面相应的新颖一些。另一个更为成熟的开源 CI服务是 Jenkins，Gitlab一直没有提供对 Jenkins的支持，倒是 Jenkins社区提供了支持 Gitlab的插件。Gitlab如果内置对 Jenkins的支持，使用起来会更方便，比如 Gitlab内置了对 JIRA的支持，开发者可以在 commit message 里提一下 Closes #MyPrj-7，代码推送到版本库之后，Gitlab会通知 JIRA修改对应的 issue的状态。

所以嘛，既然上了 Gitlab，那就 Gitlab-CI吧。麻烦的是，东西太新，资料较少，折腾起来费劲。

首先当然是安装环境，如果机器富裕，直接用Omnibus安装包安装就好了，会更容易一点。我这没那么宽裕，所以是在一台 Docker服务器里折腾。

首先当然是做好 Docker环境了，然后参照https://peteris.rocks/blog/docker-gitlab-and-gitlab-ci/的说明进行安装。这个说明是能找到的最详细的傻瓜式教程了，不过还是有几个重要细节没提到，半道上出各种问题，还是得回头去看 github上原始的项目，好在sameersbn的说明文档很详细，重要的信息都在。现在看我这个改良版就行了，当然要愿意踩一遍坑加强一下感受，也是群众喜闻乐见的。

安装过程如下：

1. 安装 gitlab，这部分还挺顺。不过 Peteris Rocks 的命令少了几个环境变量，在 Gitlab里创建的项目提示的 repo都是基于 localhost域名的，email用户也没写会发不出邮件的。

另外，所有的容器我都加上了 --restart="always"，这样机器重起后就不用手工起动容器了。

EMail的话建议给 gitlab专门开一个用户，默认会用 GMail  SMTP，国内的服务器小心连不上。

#创建 Redis缓存服务，其实不是必须的。

docker run --name=gitlab-redis --restart="always" -d sameersbn/redis:latest

#创建数据库，喜欢 MySQL的话去 github上看说明，我还蛮喜欢 Postegresql的，有几年工作就跟丫博斗。

docker run --name=gitlab-postgresql --restart="always" -d \

  -e 'DB_NAME=gitlab' -e 'DB_USER=gitlab' -e 'DB_PASS=gitlab' \

  -v /opt/gitlab/db:/var/lib/postgresql \

  sameersbn/postgresql

#终于干正事了，创建 GitLab容器。

#VIRTUAL_HOST=dev.my.com这个环境变量对于 GitLab没用，是给还没安装的 nginx-proxy准备的，后面会说明。

#GITLAB_*是用来生成 GitLab配置文件用的：

#    HOST一定要写外部ip或域名，不然  GitLab 网页上提示的代码库 URL全是 localhost的;

#   两个 PORT分别是 web服务和 ssh服务在 docker容器上的端口

#SMTP_*自然是配置怎么往外发邮件的，默认用GMail，我倒是挺喜欢 GMail的，可惜身在墙内呀。

#第一个 -v是将 Docker Host也就是主机上的 /home/git/data目录映射到容器内用来存储数据，不然容器一关数据就没了。

docker run --name=gitlab --restart="always" -d \

  -e 'VIRTUAL_HOST=gitlab.my.com' \

  -e 'GITLAB_HOST=gitlab.my.com' \

  -e 'GITLAB_PORT=10080' -e 'GITLAB_SSH_PORT=10022' \

  -e 'GITLAB_BACKUPS=daily' \

  -e 'GITLAB_CI_HOST=ci.my.com' \

  -e 'SMTP_DOMAIN=ym.163.com' \

  -e 'SMTP_HOST=smtp.ym.163.com' \

  -e 'SMTP_PORT=25' \

  -e 'SMTP_USER=gitlab@my.com' \

  -e 'SMTP_PASS=<你的密码>' \

  -p 10022:22 -p 10080:80 \

  -v /opt/gitlab/repos:/home/git/data \

  -v /var/run/docker.sock:/run/docker.sock \

  -v $(which docker):/bin/docker \

  --link gitlab-postgresql:postgresql \

  --link gitlab-redis:redisio \

  sameersbn/gitlab

注意：第一次启动 GitLab会在 compile assests之类的环节工作很久，在完成之前访问 10080端口应该会出 502或者503错误，这是正常的！你可以用 docker logs git-lab 看看进行到哪了。如果看到下面这一堆就是好了：

2015-04-22 01:46:06,781 INFO success: sidekiq entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

2015-04-22 01:46:06,781 INFO success: unicorn entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

2015-04-22 01:46:06,781 INFO success: cron entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

2015-04-22 01:46:06,781 INFO success: nginx entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

2015-04-22 01:46:06,781 INFO success: sshd entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)

2. 用默认的 root / 5iveL!fe帐号登录，强烈建议在 profile里把 root用户改个名字。

3. 到 Admin Area的 Applications菜单里创建一个 OAuth2 Application，callback url 填http://ci_domain_name/user_sessions/callback。

这不是凭空变出来的，安装好 GitLab-CI以后它会提示你用这样一个 url去创建 app，不过 ci_dommain_name部分极有可能是 localhost或者 docker internal ip，不要用这个值，不然下一步你会发现 GitLab-CI网站上回 Gitlab进行 OAuth授权的链接都点不开。

把 GitLab生成的 AppID和AppSecret都记下来，或者开着这个页面别动也成，一会要用。

4. 安装 GitLab-CI，注意传给新容器的环境变量里有 AppID 和 AppSecret，值改成上一步记下来的。

Peteris Rocks没提这两个重要的环境变量！如果已经把 GitLab-CI运行起来了，docker rm gitlab-ci重来吧。

#GITLAB_*说明 GitLab服务在哪里，虽然已经  --link了，但是要是不想被一堆奇奇怪怪的 URL困扰，_URL还是写上吧。

#-v让容器把数据库等文件存到 /opt/gitlab-ci/data里，

#   如果练手时 rm gitlab-ci-postgresql了，再创建容器时会报数据库已经存在了，这时可以去这个目录把 db目录删了。

docker run --name=gitlab-ci --restart="always" -d \

  -p 11080:80 \

  -e 'VIRTUAL_HOST=ci.my.com' \

  -e 'GITLAB_URL=http://gitlab.my.com' \

  -e 'GITLAB_APP_ID=刚才生成的ID' \

  -e 'GITLAB_APP_SECRET=刚才生成的密钥' \

  -e 'SMTP_DOMAIN=ym.163.com' \

  -e 'SMTP_HOST=smtp.ym.163.com' \

  -e 'SMTP_PORT=25' \

  -e 'SMTP_USER=gitlab@my.com' \

  -e 'SMTP_PASS=<密码>' \

  -v /opt/gitlab-ci/data:/home/gitlab_ci/data \

  -v /var/run/docker.sock:/run/docker.sock \

  -v $(which docker):/bin/docker \

  --link gitlab:gitlab \

  --link gitlab-ci-postgresql:postgresql \

  --link gitlab-ci-redis:redisio \

  sameersbn/gitlab-ci

5. 用浏览器访问http://ci_domain_name/，然后点击右上角的 GitLab Login，会跳到 GitLab。

它怎么知道 GitLab在哪里呢？创建 GitLab-CI容器的命令里给的环境变更GITLAB_URL呀。

登录、授权之后，浏览器会跳回 GitLab-CI，现在 GitLab-CI就装好了。它会提示你：

Now you need Runners to process your builds.

Checkout the GitLab Runner section to install it

呵呵。

6. 最后装上 nginx-proxy做为反向代理，这样就可以直接用各个容器的域名直接访问网站，而不用记那些奇怪的端口了。

#这个容器会监视所有的 docker容器的启动，并扫描容器内部的 80端口映到 docker host哪个端口了，然后在 nginx里建对应的虚拟主机，将该容器的域名(由容器内的环境变指定)上的HTTP请求转发过去。

docker run -d --name="nginx-proxy" --restart="always" -p 80:80 \

      -v /var/run/docker.sock:/tmp/docker.sock jwilder/nginx-proxy

7. 没找到 gitlab-ci-runner-meteor，自己动手做吧。动手前搞清楚 GitLab CI Runner 是怎么工作的非常有必要。

GitLab官方已经把Runner环境程序都弄好了，放在https://gitlab.com/gitlab-org/gitlab-ci-runner项目里了。我们并不需要从头写程序访问 GitLab CI 的 API才能制作 Runner环境。

1. 把gitlab-ci-runner.git取一份回来
2. 在里面 bundle install --deployment 进行安装
   1. 自然需要先把  ruby/gem/bundle 这堆环境都准备好。
   2. 安装后，默认的工作目录：/home/gitlab_ci_runner/gitlab-ci-runner
   3. 配置文件在工作目录里：config.yml

3. 在里面 bundle exec ./bin/setup_and_run完成设置并启动运行。

这一步需要 CI-Runner容器能够顺利访问 GitLab服务器(注意不是GitLab-CI而是GitLab)，以便检出代码。以ssh方式的话需要安装信任证书。

1. (以下是 2015-4-20左右的代码情况，即使有变化原理应该也差不多的)

2. setup_and_run脚本会读取以下环境变量
   1. CI_SERVER_URL：CI服务器地址(http://ci.my.com)
   2. REGISTRATION_TOKEN：初次访问 CI 服务器的令牌(http://ci.my.com/admin/runners会显示)
   3. RUNNER_DESCRIPTION：Runner的说明，不提供的话则使用 runner运行环境的 hostname
   4. RUNNER_TAG_LIST：还没弄明白
3. 然后构造一个 json对象， HTTP POST给 GitLab-CI的 API：

CI_SERVER_URL/api/v1/runners/register.json

BODY:{

    token:REGISTRATION_TOKEN,

    tag_list:RUNNER_TAG_LIST,

    description:RUNNER_DESCRIPTION

}

4. 注册成功的话，会从 CI服务器取回一个授权令牌，以后用这个令牌与 GitLab-CI通信。
5. 开始每5秒钟问一次 GitLab 有没有新 Build
   1. 就是把一个只包含注册时得到的 access token的对象 HTTP POST给：

CI_SERVER_URL/api/v1/runners/register.json

2. 如果 GitLab-CI说有变化了，那么临时生成一个 bash脚本并执行之
   1. 项目源代码会放在工作目录之下：tmp/builds/project-id
   2. git fetch repo (第一次则 clone之)
   3. git checkout $ref (ref由服务器返回的信息里提供)
   4. 依次执行 GitLab-CI返回信息里的 commands数组里的每一条命令
      1. 这些命令可以使用以下环境变量来获取必要的信息：
         1. CI_SERVER='yes'
         2. CI_SERVER_NAME='GitLab CI'
         3. CI_BUILD_REF, CI_BUILD_BEFORE_SHA, CI_BUILD_REF_NAME, CI_BUILD_ID, CI_BUILD_REPO, CI_PROJECT_ID
         4. CI_PROJECT_DIR(这个是 Runner本地工作目录)
      2. 所有命令要在指定时间时结束，默认是7200秒，GitLab CI 服务器可以为项目指定不同的值。
      3. 命令的 stdout和 stderr都转向一个临时文件；
      4. 所有命令的输出，以及异常情况都会合并成 trace信息；
      5. 任意一条命令失败，则中止执行，并将执行状态标记为 failed；
      6. 所有命令都成功完成，则标记为 sucess状态；
   5. 将 build的命令执行状态、trace信息发回 GitLab-CI。
      1. 就是把 state和 trace拼成一个 json对象，HTTP POST给

CI_SERVER_URL/api/v1/builds/{id}.json"(id是GitLab-CI给的build id)

8. 总结一下：
   1. GitLab CI Runner是用 ruby做好的一套 Runner环境。
   2. GitLab-CI服务器会把工程信息以及一组命令发给 Runner。
   3. GitLab CI Runner 会自动取出源代码，然后执行收到的命令。
   4. GitLab CI Runner会把命令执行的结果、出错时的 trace一起发回 GitLab-CI。

所以制作 meteor velocity runner就是要把环境准备好，然后用让项目调用 meteor run --test，用 console reporter 输出测试进度，测试失败时meteor run返回一个非0值即可。

话说，GitLab CI Runner其实简单，为此搭上一堆 ruby环境其实挺不值当的，什么时间有空拿 node.js重写一个就完美了。显然我不是第一个这么想的人，https://github.com/evanlucas/gcr已经做了。

9. 要将 meteor velocity runner做成 docker，倒是简单的。

从头写个 Dockerfile也没多麻烦，https://registry.hub.docker.com/u/vdubyna/gitlab-ci-docker-runner/就是个从头写的例子。直接用 docker hub上做好的也有，比如 bobey/docker-gitlab-ci-runner-node就不少人用。我们前面都在用 sameersbn的工作成果，其实也有一个 sameersbn/gitlab-ci-runner。用 Trusted Build派生一个环境多少能省点事。不过既然找到了 gcr，就做一个这样的吧：

• docker-node：提供 node.js运行环境，跟 sameersbn的几个东东一样基于 ubuntu:latest，虽然  debian会更小一点。
  • docker-gitlab-ci-runner-node：加上 gcr 。
  • docker-meteor：加上 meteor 。
    • meteor-gitlab-ci-runner：加上 gcr 。

10. 正常运行的 Runner在 GitLab收到代码之后

gcr info [client] checking for builds...

gcr http 201 http://ci.my.com/api/v1/builds/register.json

gcr info [client] submitting build 1 to coordinator...

gcr http PUThttp://ci.my.com/api/v1/builds/1.json

gcr http 200 http://ci.my.com/api/v1/builds/1.json

gcr info [client] submitting build 1 to coordinator...

gcr http PUThttp://ci.my.com/api/v1/builds/1.json

gcr http 200 http://ci.my.com/api/v1/builds/1.json

gcr info [client] submitting build 1 to coordinator...

gcr http PUThttp://ci.my.com/api/v1/builds/1.json

gcr http 200 http://ci.my.com/api/v1/builds/1.json

gcr info [client] submitting build 1 to coordinator...

gcr http PUThttp://ci.my.com/api/v1/builds/1.json

gcr http 200 http://ci.my.com/api/v1/builds/1.json

gcr info [client] submitting build 1 to coordinator...

gcr http PUThttp://ci.my.com/api/v1/builds/1.json

gcr http 200 http://ci.my.com/api/v1/builds/1.json

gcr info [client] submitting build 1 to coordinator...

gcr http PUThttp://ci.my.com/api/v1/builds/1.json

gcr http 200 http://ci.my.com/api/v1/builds/1.json

gcr info [runner] build success [1]

11. Velocity自身的 CI模式。

Velocity如果读到环境变量VELOCITY_CI 有设置的话，就会以 CI模式运行，具体说就是在development环境里，会对每个已注册的testFramework调用 /reset和 /run，也就是每次运行时会把所有类型的测试都执行一遍。

!目前碰到的问题是 Mocha的 client tests不会执行，在Host Ubuntu 14.04里是好的，可见是 ubuntu:latest这个环境里有什么不对，还没有找到解决办法。怀疑是 Mocha对于 headless linux支持有问题，但是  mike:mocha里其实有PhantomJS的脚本，不过文档里没有提到类似 JASMINE_BROWSER=PhantomJS的选项，代码里也还没找到怎么启用这个脚本。测试下来 Jasmine的 client unit也有它的问题。

测试下来，2G内存的虚拟主机跑这个全 docker 的CI环境还是太免强了。还是直接在 VPS里搭环境省心。虽然 Docker 具有迁移方便的优点，不过将来把 GitLab/CI/Runner分别迁到自己的服务器里其实也没多麻烦。