关于微服务项目的 GitLab CI 如何写？

不支持 make ，支持 sh 不 ？

都 mono repo 了为啥不用一个镜像，运行时做下区分，不同服务走不同逻辑就可以了

onedev

@kiwi95 这个问题不讨论，微服务化逐步拆分中。

@BeijingBaby 是个方法，

gitlab-runner 运行的环境下该怎么打包就怎么写呗。和镜像环境没关系，你可以外面（ runner 所在环境）编译完后再打包到 docker 运行环境的镜像里。

规定 tag 规则，然后通过正则匹配 tag 触发

都是先编译完再传镜像啊，万一镜像有问题，你还有 build 结果，gitlab ci 不就支持多个阶段么

和 7#的原理一样， 根据 commmit 写正则匹配微服务执行构建就行

是 Mono Repo 而不是 meno

@clf 这个项目有十个微服务了，ci 里写十遍生成镜像，有点傻。并且每增加一个服务，都要在 ci 里增加一份流程。不太像合适的做法。

@basefas 这个是触发单个服务的更新，我主要是问的全量更新的时候，十个服务要在 ci 里写十遍吗？

@SingeeKing 感谢指正

@BeijingBaby 编译镜像使用的 kaniko executor ，不支持 sh

@xyqhkr #11 ci 脚本里自己读取一下服务，或者采用配置文件的方式决定发布哪些服务，然后执行打包就行了，又不需要把同样的东西复制十多个。
另外，gitlab-ci 是可以监听代码变化决定触发的，你可以做到 A 服务相关代码变动，执行打包 A 服务 CI……监听到 release 分支创建了 version tag ，再全量打包到 release version tag 上。

（一般情况下微服务项目更多的是单仓库单服务节点的模式）

我看了一下 kaniko executor ，这玩意主要还是执行 Dockerfile 的打包逻辑，它是用来构建镜像的，不是必须要在里面编译代码，你可以在外部编译完后复制进容器里，也可以在容器里执行环境安装脚本后再编译。

@xyqhkr #12 全量一样，定一个一个 tag ，然后匹配，Gitlab 的话，应该只能这么用

@clf （一般情况下微服务项目更多的是单仓库单服务节点的模式） 这句话不太对哦。现在一般都是 Mono Repo 模式。

我提 kaniko executor 是因为要在 ci 步骤里写 Dockerfile 打包步骤，编译阶段在这之前已经处理完成。你没提在这个阶段，如何实现全量打包 10 个微服务的问题。因为使用 kaniko executor 必须基于 kaniko 镜像，该镜像对 shell 支持不友好。除非我写 10 次 kaniko executor ，不然想不到 如何打包多个镜像。