GitHub持续集成CI

记录一下个人是如何选择GitHub CI工具并进行相关配置，目录如下，

0. Overview
1. CI选择
2. 配置AppVeyor
3. 编写配置文件
4. 遇到的问题
5. Reference

---

Overview

CI的好处之一就是能够在每一次push的时候，检测新提交的code是否能够通过test case乃至是否能够顺利打包。

"持续集成并不能消除Bug，而是让它们非常容易发现和改正。" ---- Martin Fowler

---

1. CI选择

GitHub上面默认推荐了7种CI供应商，

• CircleCI，个人首先选择的是CircleCI 2.0，但由于其Scala使用的是sbt来build，与个人当前项目所用Maven不一致，所以弃了
• Travis，接着看到了Travis CI，点进去之后一看默认跑到收费试用栏，当然它可以选到FLOSS(Free/ Libre Open Source Software)免费版
• AppVeyor，最终选择了AppVeyor作为个人项目的CI工具，第一点是自定义语义丰富，第二点是免费，第三点是Spark用的也是它

GitHub推荐的CI供应商

CircleCI UI Controller

---

2. 配置AppVeyor

AppVeyor提供了两种方式来进行配置，

• UI的SETTINGS栏
• 上传配置文件appveyor.yml到GitHub项目的根目录（推荐）

UI的SETTINGS栏

---

3. 编写配置文件

配置文件appveyor.yml可自定义，具体可以参考Spark的写法。

---

4. 遇到的问题

在整个配置AppVeyor的过程中，遇到了下面两个问题，

1. AppVeyor默认安装了Maven，可以不用像Spark那样每次都安装一遍
2. 配置好了之后Build success了，但是发现没有覆盖到test case。原因是Maven的pom文件没有配置plugins，配置了相关plugins之后，出现了No sources to compile，排查后发现原来是自己在pom里多写了pluginManagement tag，导致root的plugin不起作用

至此，完成了基本的GitHub CI配置，而更深入的CI功能还待熟悉。

11-master log

---

Reference

• 用 AppVeyor 持续集成 Github 中的 JS 项目
• Apache Spark
• 个人CI项目