doujuanxun7167 2019-07-17 13:46
浏览 56
已采纳

如何为CI组织两个git repos

I have a git repo "core" and "project" repo, that is using "core" as dependency. If I want to change some API of "core" module, and its usages in "project", I create two separate pull requests in gitlab. But our continuous integration system can't test "project" until "core" will be merged, if "core" contains API changes. What I want, is the possibility of "project" test will go on the same branch in "core". For example if I created branches "feature-42" in "project" and "core", the "project" tests will start on the "feature-42" branch of "core".

Now we have an opportunity to move at go modules, but it is hard to always specify the direct commit hash in go.mod file(many possibilities to made a mistake). It looks like we should use monorepo, but I scared of the possibility our project will become monolith (considering that we have not very qualified developers).

How can we organize our continuous integration?

P.S. also we don't wanna use tags with version, because people works in parallel, and it is hard to maintain always non-decreasing versions.

  • 写回答

1条回答 默认 最新

  • doucha7329 2019-07-29 19:21
    关注

    Your go.mod file can specify an explicit commit of a dependency — even if that commit is on a branch! — as long as the commit has actually been published to that repository.

    So if you publish a feature on the feature-42 branch of core and want to use that in project, you can run go get core@feature-42 within the project module and you should get a version that includes that feature.

    (The go command knows how to resolve a branch name to a specific commit in general, so you shouldn't need to name the commit hash explicitly. However, the go.mod file will record a pseudo-version with the resolved hash.)


    As another alternative, you could add a go mod edit -replace command to your CI system, to have it explicitly replace the selected version of the core module with the branch in question.


    All that said, it sounds like it would probably be simpler for you to switch to a monorepo, perhaps with a single go.mod file at the repo root so that everything is versioned in lock-step. In my experience, the best way to avoid a Go project turning into a monolith is through the use of internal packages, not separate repositories.

    本回答被题主选为最佳回答 , 对您是否有帮助呢?
    评论

报告相同问题?

悬赏问题

  • ¥66 定制开发肯德基自动化网站下单软件
  • ¥20 vscode虚拟环境依赖包未安装
  • ¥15 odoo17关于owl开发js代码问题
  • ¥15 光纤中多普勒频移公式的推导
  • ¥15 怎么制作一个人脸识别门禁系统
  • ¥20 大华dss监控平台网络关闭登不进去
  • ¥15 请使用蚁群算法解决下列问题,并给出我完整的代码
  • ¥20 关于php录入完成后,批量更新数据库
  • ¥15 请教往复密封润滑问题
  • ¥15 cocos creator发布ios包