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_第1张图片
GitHub推荐的CI供应商
GitHub持续集成CI_第2张图片
CircleCI UI Controller

2. 配置AppVeyor

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

  • UI的SETTINGS栏
  • 上传配置文件appveyor.yml到GitHub项目的根目录(推荐)
GitHub持续集成CI_第3张图片
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功能还待熟悉。

GitHub持续集成CI_第4张图片
11-master log

Reference

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

你可能感兴趣的:(GitHub持续集成CI)