author：潘伟洲
需求描述
在 上一篇文章 中，我简单描述了我们一个项目的复杂程度：子模块、嵌套子模块、多分支。除了工程分支切换上的复杂，我们还遇到另一个问题：子模块持续集成。
主工程持续集成
先说说主工程如何做持续集成。我们使用 Gitlab 自带的 Gitlab-Ci 作为我们的持续集成系统。Android 端的主工程的持续集成脚本如下：
build:
tags:
- android
script:
- ./fmanager checkout -f $CI_BUILD_REF_NAME
- ./fmanager update
- gradle clean
- gradle aR其中， CI_BUILD_REF_NAME 指定要编译哪个分支的主工程。当我们推送代码到某个分支时，该分支下的持续集成脚本就会被调用，CI_BUILD_REF_NAME 变量就会是那个分支的名字。在执行构建前，先用 fmanager 完成主工程和所有模块的分支切换 ，之后再用 fmanager 更新整个项目的代码。最后再执行编译指令。
主工程的持续集成就是这么简单。然而这远远不能满足我们的需求：我们的工程有多个子模块。一个子模块的某个分支可能被多个父模块的多个分支依赖。例如，common 模块的 master_dev 分支可能被 framework 模块的 master_dev、jilin_dev、taishan_dev 分支依赖。在这样的情况下，任何一个子模块如果不注意提交前自测，都有可能导致多个分支的整个工程编译失败，阻塞多个分支的开发进度。比这更困难的是，对某个模块的修改也许可以保证在当前主工程分支上编译通过，但却意外导致了另外一个依赖该子模块的主工程分支的编译失败。
因此，我们除了要对主工程进行持续集成测试之外，也不得不对子模块做持续集成测试：任何一个子模块某个分支一旦推送了代码，就触发所有依赖它的主工程的分支的持续集成测试。为了实现这个目标，我们尝试了三种方案。
温馨提示：请单击右下角的 [阅读原文] 阅读完整文章。
本文分享自微信公众号 - HaHack（gh_12d2fe363c80）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
