Fork一个Github仓库然后Pull Request的一波三折

wentianen 2016-03-28

 Fastlane是一组工具套件,旨在实现iOS应用发布流程的自动化,并且提供“一个运行良好的持续部署流程,我们公司的iOS项目持续集成和持续发布都依赖这个框架,由于整个过程高度自动化,所以帮我们节省了很多时间。
 
自己也写过一个Fastlane的action,用于执行私有库pod lib lint命令,因为自己用了一段时间,感觉还不错,所以想发布到Fastlane的master分支上分享给大家,于是Fork了一个Fastlane的仓库,
新建了一个feature分支add_action_pod_lib_lint准备做Pull Request。
 
首先阅读了Fastlane的Pull Request规则,需要将此分支的所有Commit通过Rebase命令合并成一个。
于是按如下步骤执行:
(1)git rebase -i HEAD~2(这个2代表Pick最近的两个Commit)
(2)在Vim里编辑,然后选择sqaush方式,将前一个Commit合并到当前选中的Commit
(3)继续在Vim里编辑合并后的Commit信息
(4)合并成功,然后git push -ff覆盖远端分支的提交信息
 
 
接下来,提交Pull Request,提交后发现Github的CI做的相当好,分两步进行:
(1)使用一个叫做Hound-Bot的服务Check你的代码语法规范(大概看了一下,Hound服务对于开源项目是免费的,很棒)
(2)使用Circle CI跑一遍单元测试
 
执行(1)的过程中发现了2个Violation,基本都是一些格式上的错误和语法上不太严谨的地方,比如:文件的最后一行要给一个空行。
看了一下没什么大不了的,于是直接忽略了。
执行(2)之后,发现test没有通过,登到Circle Ci上发现居然给出的结果是:
Your build ran 1733 tests in RSpec with 0 failures
 
感觉很奇怪啊,明明全部通过了啊,不明白错误究竟在什么地方,难道Circle CI这么智能,发现我的单元测试的Case并没有覆盖所有场景?(因为很简单,所以犯懒只写了两个Case)
于是补全了一下测试,继续重复之前的步骤,结果依然是不通过,彻底郁闷了!于是仔细检查了一下Circle CI的每一个测试步骤和Console中打印的信息,终于在一个很不起眼的地方发现了问题:
fastlane: Command failed with status (1): [bundle exec rubocop...] rake aborted!
 
晕,原来Circle CI也会使用Rubocop进行静态检查,当然也包括语法格式规范之类的,看来不应该忽略Hound-Bot的警告啊(突然想起一个程序员和警告的梗)。
 
最后将所有语法全部规范化,再次Pull Request,这回终于OK了。
All checks have passed
2 successful checks
Details ci/circleci — Your tests passed on CircleCI!
 hound — No violations found. Woof!
 
This branch has no conflicts with the base branch
Only those with write access to this repository can merge pull requests.
 
接下来就等待排队Merge到Master分支了 

相关推荐