1

2

在 CI 的描述语言里直接写代码就是邪路啊，既不方便管理也不方便迁移。
不都是写在各种 bash / python / powershell 这种脚本里，然后 ci 只负责调用和设置环境变量么

3

1

关于: 是应用 CI 自身的模块来编写更原生化的 pipeline, 还是使 CI 基本仅负责调用,组织和粘合 shell/python script 的执行.
我个人倾向于后者, 确实是会更方便在多种 CI 工具之间迁移.

4

密码有个叫 sealed secret 的工具，可以以加密形式在代码中直接储存密钥，然后在 k8s 中再还原为 secret

5

@FlytoSirius 前几天刚把 CI 从 Jenkins 迁移到 Gitlab Pipeline 上。迁移的时候做了亿点点改造，改完之后基本和你说的一样，CI 仅负责基本调用，主要逻辑都在 Python 中实现。
Gitlab Pipeline 被触发后，设置一系列的环境变量，调用 Python 脚本。在 Python 脚本里做真正的工作：解析环境变量，编译，跑单测、归档啥的。
这样本地开发调试脚本也方便，后续迁移 CI 平台也更容易。

6

我们的构建脚本全都拿 PowerShell 写的,CI 只是负责传递参数和调用，所以无论迁移到哪个平台都很简单。

7

8

9

我的做法：jenkins pipeline + nacos
为什么不上 k8s secret/config 而用 nacos：项目小，方便

10

makefile 或者 justfile 实现具体细节，比如文件拷贝和编译
ci 主要是利用平台的权限拉取代码，和最终的上传到制品库，运行是传入参数啥的调用 makefile 之类的，这样迁移成本小

11

@FlytoSirius #8 Bitnami Sealed Secret 就是为了解决如何把加密过的密码（或任何 secret ）放在 git repo 里诞生的，解决 "I can manage all my K8s config in git, except Secrets." 的问题。Sealed secret 使用证书生成加密过的 secret.yaml 便于安全存放在 git repo 中，在 apply 到 k8s 集群后通过 controller 解密为正常 base64 enc 的 secret 。

12

确实有这种问题，用 pipeline 迁移不好弄，我们现在基本上全是用 bash 写的脚本，然后通过 jenkins 传入环境变量

13

我自己的项目用的 drone,凑活能用

14

用 gitlab 的话当然首选 gitlab ci ，不仅方便，而且还有 gitlab 自带的 ci/cd 标签，可以放在 readme 里，这精美小标签反正我是没法拒绝

15

试试 teamcity ，UI 好看，前段时间从 jenkins 全部切到了 teamcity

16

jenkins 支持在它界面里配置密码这些 ，k-v 形式。pipeline 里面用 key 去获取。不过可能是商业版才有

17

shell 打倒一切

18

我们是自己开发的平台，调用 Jenkins 的 API 做打包发布，没有使用 Jenkins pipeline ，更适合自己公司的场景吧

21

22

gitlab 纯跑 ci 。cd 自研中。。
受够了 jenkins 那个破 ui 还有非常不自然的逻辑了

23

@defunct9 原来 teamcity 有免费的自托管版本，之前还一直必须收费呢，下次试试！我也受不了 Jenkins 那上古的 ui ，相信 jetbrain 家的产品品质应该会没问题

24

国内制造业，Tekton+自研 UI ，不管是原来用的 Drone 的还是现在 Tekton ，针对每个 Step 就做参数变量化的管理，目的就是可移植且更容易推进各业务 IT 的 CI 标准化

25

可以考虑 drone 或者其开源代替，woodpecker ，Jenkins 管理起来比较麻烦，可以作为第二选择