目前正在使用 Jenkins 进行 cicd ，最近想要换个一个 cicd 工具，看来好几个基本都是推荐的 gitlab runner ，不知道有没有其他推荐的

统一回复一下，因为是公司内网用的，saas 服务类的只能放弃的，关于 drone ，supg ，teamcity ，onedev 等之类打算都部署体验一下看看效果

drone?

spug 啊... 放弃 java 东西，开机就吃你内存。

建木？

私有化的话 -> Gitea ，相比 GitLab 轻量多了，GitLab 有点太重了，个人的成本太高。
公有云的话 -> cnb.cool ，流水线功能和 GitLab 一样基于容器技术，速度非常快，对 GitHub 等境外网站有网络优化。

teamcity

云效

为什么要替换掉 Jenkins

我在传统公司 感觉用着还行 但是插件确实有点乱以及难用 但是免费开源的东西么

jb 公司的 teamcity, 界面好看功能齐全

如果你们已经用了很长时间 jenkins 了，那很难换，因为别的 cicd 工具都没有 jenkins 来的灵活，自由
argo cd, drone ci, 建木, travis

确实不好换。 大概被广泛使用的备选只有 gitlab 啦

替换只有自研

onedev 很好用

轻度用过 jenkins 各种插件版本管理太混乱了，经常出兼容性问题，界面看着也乱，放弃了。
让后用了半年左右的 gitlab ， 配置文件太抽象，而且性能很差，可能是我太菜吧。
最终选了 teamcity 用了有三年了吧，已经完全融入到工作中了，不需要操心，配置也非常直观便捷，以至于我对他都没啥印象了 总之就是好用。

spug 非常好用

teamcity 。比 JK 好用太多了。

🙄同样感觉 jenkins 难用，官方文档就基础的 DSL 语法，想写出牛逼的还得学 groovy ，groovy 的很多有直接用 java 的语法和库啥的。有时候一些场景实现都只能在 StackOverflow 和外国论坛上看到大佬们的 groovy 片段啥的。

jenkins 又重又难用，但是没啥好替代的

Jenkins 相对比较灵活，可以实现你想实现的任何东西，代价就是比较重。不知道你想替换 CICD 工具是为了实现什么目的，以及发布的环境架构。如果是传统架构，最好是先转到容器化 K8S ，这样 CICD 工具就方便选多了。

teamcity 收费的呀

免费版多部署几个的事

要不就是 gitlab ci 要不就是 drone 。感觉各有各的问题。 感觉本质上没有什么换的必要。。 不过 jenkins 的 IaC 确实不好用

flowci.github.io/＃/cn/
开源的，好几年了界面好看很多，之前小公司我自己用。

tc 也不好用，凑合用得了

有没有大佬讲讲用 GitHub Actions 替换怎么样

drone 我感觉还是不错的，但是复杂的嵌套流水线估计比较困难

传统的 CI 考虑 TeamCity 就行，跟 TeamCity 比 Jenkins 坑真的多。

我 N 年前写的 TeamCity 插件现在还能用，但 Jenkins 就废了。这东西基本上锁死在你最初搭建的那个版本上。功能基本全靠一堆破插件，破插件之间还有互相依赖关系。等用一段时间你就发现，你想要一个功能，需要一个新插件。新插件需要新版本的 Jenkins ，但你要是更新 Jenkins ，你有个老插件的依赖插件就没法用了。导致你整个功能会挂掉。

Jenkins 属于成也开源败也开源的典型。让你深切体会到一个复杂系统管理失控是个什么结果。只做核心功能，其他交给社区没问题。但社区插件也能互相依赖的话，一个插件作者不维护了，所有依赖它的插件全都要挂掉。可能后续其他插件也能提供类似的功能。但 CI 这种东西一旦搭建起来几十几百个项目都带在上面，不更新还有 CVE ，一更新挂掉一半这谁受得了。

TeamCity 大部分功能都是自身就有的，插件依赖度比较低。该更新就更新，从来不会有问题。免费版 100 个配置 3 个 Agent 基本也够用了。

但说实话，最方便的还是现代 CI 那种配置文件+Docker 的。虽然配置麻烦一点，但一般一个项目也就配一次。

没人用 Azure DevOps ？

我用的 drone 还是感觉很不错的， 写 yml 就行了， 搞一个服务端，多个部署端， 通过配置 yml 随机部署到任意一台服务器上

github.com/opsre/JenkinsGuide

已开坑，写了五六篇了，以后会慢慢更新。

＃17 同感，pipeline 文件参数就鸡肋，也是从 StackOverflow 找到大佬的 groovy 解决方案

onedev 不久完事了

jenkins 还可以啊

drone ci 不错

drone 稳定省心

spug 呀，非常好用，不仅能满足你的发布需求，还能满足你管理服务器、监控报警、任务计划、在线终端等运维需求。开源地址： github.com/openspug/spug

jenkins 挺好的，灵活。gitlab 本身占用比 jenkins 还大。Drone CI / Harness 基本就维护了（个人观点）

没有集群化部署需求，且有历史债在，Jenkins 还是丢不掉。

否则，你可以试试 argo 全家桶（需要自己实现完整的逻辑，但是云原生友好，和 k8s 高度集成），
gitea action （和 Github Actions 很像），
drone ci(功能比较残缺的 GitHub Action 简化版)

gitlab 的话，习惯也可以用。

drone 还不错，基于 docker 的，现在自己定制了 docker 镜像+开源镜像搭配使用，还蛮稳定的。界面也还不错

buddy works ，没人用这个吗？感觉还行，就是收费

楼上好几个回复 spug, 看下官方文档 spug 商用也是收费的

手写 python 部署代码

Gitea Actions 怎么样，有大佬用这个吗

我们搞了一套,但通用性不强,后面切 drone 了

支持协作嘛 想着有部分有一些个人的见解或者 在一些约束下取巧的方法
纯 fork 还是 可以提 PR

teamcity

TeamCity ，学习曲线平滑

最近更新了新 UI 把 setting 模式区分出来了易用性更上一层楼。

还不错，语法和 GitHub Action 兼容

一样的头像

不是，楼上一堆推荐的 spug 是托吧？看个 demo 都要微信关注才能拿体验账号。

而且看了一下文档，更像 saltstack 和 ansible 之类的主机管理，跟 CI/CD 和 Jenkins 有什么关系？

能用 gitlab 、gitea 的 CI/CD 的生态位其实跟 Jenkins 和 TeamCity 差得挺远的。能用 CI/CD 就不会用 Jenkins 。

我觉得不管 OP 你用啥，都可以考虑把基于 CICD 平台的东西尽可能用 docker build stage 来搞，这样不用太依赖平台，后期你就算换也比较容易

目前团队在用 tekton , 从 Jenkins 转过来的

非常欢迎提 pr 。

github action ，drone

近期发现 jenkins 会出现卡住假死的状态，看了监控也不是 cpu 、内存资源的问题，而且现在的 Jenkins 插件有好多开始不维护，会有提示不可用的，就想着替换掉

TeamCity 咯，相当于不用怎么折腾的 jenkins

是 JetBrains 的产品吗？这去了解一下

感谢，这边去了解一下

是的现在 Jenkins 有好多插件都不能用了

没有，试过很多 ci 工具，都没有 jenkins 傻瓜，可以让不懂编程的也能用，这是 jenkins 最大的优点

onedev 还行，其实问题也不少，权限管理，CD/CD 模板共享等。
drone 早就被收编，现在是 harness 的一部分了，harness 包含完整的 CVS ，CI/CD ，一年多以前使用问题还很多，仅供参考。
Github action 不错，所以可以推荐可私有化部署的 gitea ，也支持了相似的 act 。不过指令支持的不全。
gitlab 除了重了点，还是不错的。

当然个人很不喜欢把 CI/CD 相关的文件放到 CVS 工具中和代码一起管理。所以又选择了 devtron ，但是其用户管理和 Helm 模板功能不太行。

teamcity 用着还不错

我白嫖 github action 非常棒。

不知道大家使用 gitea action 体验咋样？

为啥会？期望解决啥问题？能带来啥收益？

argocd ，根 gitlab 联动很 nice

gitea 在公司用了近两年了
跟 github action 体验近乎一样 只不过尽量选择适合的镜像
比如 catthehacker/ubuntu 有针对 js java 不同程序的镜像 jdk js 的 node 能通过
例如 切换 node

- name: Switch to Node.js 20 via NODEPATH
 run: |
 export NODEPATH="$ACT_TOOLSDIRECTORY/node/20.18.0/x64"
 export PATH="$NODEPATH/bin:$PATH"

这些搞好之后相对比 jenkins 容易配置 因为 yml 都是随项目编写的 如果有二开的情况很方便
不过缺点也有比如有些工具需要拉取 github 的应用商店 我是通过将 github 的插件同步到本地 gitea 如果有些链接需要翻墙可能还需要手动修改下同步过来的仓库
再就是额外启动 gitea gitearunner 两个项目 亲测占用不是很大比 jenkins 懂不懂 8g 起步小的很多

我用 teamcity ，很不错。

forgejo + drone

forgejo 和 gitea 基本兼容， gitea 之前搞了个骚操作，差点变成收费的， 吓得德国人 fork 出 forgejo

groovy 写的我想死，调试也困难。jenkins 也不敢更新版本，也不敢装别的插件，曾今装了一个插件，把 jenkins 搞得崩了，手动回复 Plugin 文件夹

阿里云效吧

不知道是我司的项目复杂还是 gitlab 的配置问题.一个依赖 10+的 springboot 项目,每次用 gitlab 编译,都可能报错.错误还不太一样,有超时的,有内存错误的,有加载组件错误的.反正就是动不动就错.最诡异的是,不改代码,重新编译,就又可能 OK 了.跑起来也没问题.

Buildkite?

个人感觉：Github Actions > Jenkins > Gitlab runner

Buildbot 也是一个选择，blender 就是用的这个。

buildbot.net/

Gitea Action +1

1 、轻量，省资源，不像 gitlab 那种大家伙，动不动就要几十 G 的内存
2 、gitea ation 兼容 github action ，可以直接用 github 的各种 action ，迁移简直太丝滑了，新写任务也可以直接用 github action ，非常省事
3 、gitea action 也非常轻量，底层是容器实现，随便一台垃圾主机都能丝滑运行

没有

gitea action,
GitHub 能用的都能继续用，就是要同步一些库到本地 gitea

我觉得 Jenkins 很好用，能满足我任何需求，公司有频繁构建安卓 apk 的需求，我就写 Pipeline 、写批量打包脚本，然后内部后台调用 Jenkins API ，打包完在发飞书群，在 at 打包人，实现公司人人都可以打包，好用的很，可以随意定制化

drone ci 都已经停止维护了，gitlab runner 可以试试，但是重度使用 jenkins 的用户，肯定还会回归到 jenkins ，因为同生态位没有等价替代

github.com/gocd/gocd github.com/gocd/gocd

不要用 Gitea Action ！！！和 Github Action 相比，功能支持很不全。

很多字段，比如 jobs..name , matix 没法动态模板生成。
翻过它的代码之后感觉 native 类型的 workflow 调 dockerfile 类型的 action 有大问题（没记错的话）
作为 gitea 的 fork ，forgejo 很有自知之明的在 forgejo-runner 的 readme 上写了，这是 alpha release quality 的代码，不要在生产上用 ： code.forgejo.org/forgejo/runner

spug

换来换去还是 Jenkins 好用，自由度高，gitlab-runner 能用，但是总觉得和代码一起不安全（个人见解）。资源消耗，并发构建的时候，gitlab-runner 性能不如 Jenkins

书接 ＃81
matrix 不能动态生成这个。
我的应用场景是，第一个 job 判断哪些包需要重编，第二个 job 根据第一个 job 的输出来动态生成任务个数。
这个 Github 支持，Forgejo/Gitea 是不支持的。

还有一个槽点，workflow_call 的触发方法实质上我觉得是不能用的。
如果一个 workflow (caller) 使用 jobs..uses 的方法调用另一个 workflow (callee) 。
无论你的 callee 有几个 step ，caller 只会有两步，Setup Job 和 Complete Job 。
callee 的日志全会塞在 caller 的 Setup Job 这一步里面

目前我还是倾向 Jenkins ，DSL+groovy 弄几个模板共享库，管理起来很方便，都放 git 管理，之前用 tc 没弄成，可能是姿势不对

gitlab runner 很好用的，如果公司的代码刚好又是在 gitlab 中维护的，那更完美了

用过三个，Gitlab Runner, Drone 和 Gitea Actions 。

Gitlab 没啥好说的，只要配置够，无脑选它
Drone 很轻量，基本能满足需求，不符合的可以直接写 bash 脚本
Gitea Actions 不会，虽说号称兼容 GitHub Actions ，但是由于内网部署，很多镜像用不了，之前在 V 站有大佬说把所有用到的环境镜像都打包成一个镜像就行，但是我玩不明白，主要是 GitHub Actions 不太熟。

JENKINS 最好用 其他工具换一个场景 你可能不方便了

个人使用经验，jenkins4-5 年>gitlab 不到 1 年>gitea 2 年。jenkins 运维成本比较高，适合大一点的团队。gitlab 主要是刀法太精准，免费版本功能卡的你很难受。gitea 当然不完美，不过适合中小规模的团队，简单够用。前面的人单个产品的优劣说的比较多了，我提一个点，就是你选型要看你的约束，比如团队规模，资源（比如单独的运维），团队成熟度（开发的平均水平）这些，脱离这些约束谈好或者不好意义不大，就跟哪个语言更好一样。

用过 drone ，tekton ，jenkins ，综合下来，还是 jenkins 最好用
用 docker 跑 jenkins master 节点，通过 SSH 通道连接 slave 节点，这样就可以用高主频的 SSD 家用电脑代替服务器节点，提高编译速度。
权限管理用的用户组插件。
master 上只是用下发配置的插件，step 上使用自己打包的各种编译工具镜像（这样 pipeline 基本都是人类直接执行的命令），通过 nexus 拉取，这样就不会有插件兼容性问题，因为只使用了一两个插件。
最后 pipeline && job 写成 xml 文件，通过 jenkins 自带的 cli jar 工具管理，还可以使用 git 进行版本管理。
drone 当时配合 gitea 使用的，权限管理只能用 gitea 的用户体系，不是很灵活。
用过原生的 tekton ，权限管理基本没有。

换 jenkins 最新版本。其他的没有 jenkins 好用。

开源项目： 简而轻的低侵入式在线构建、自动部署、日常运维、项目运维监控软件 jpom.top

如果你们用的 gitlab ，就用 gitlab-ci 是最简单的，然后每个项目的.gitlab-ci.yml 里面只要 include 一个统一的项目，只在这个项目里面维护流水线的详细步骤，侵入少好维护

你现在 jenkins 是怎么用的？
在 Jenkins project 这边写？还是用 jenkinsfile ？如果是后者，倒是比较符合现在的潮流

CNB 这么拉就别推荐了

怎么说？ 我是觉得 CNB 目前个人用还不错

＃55 磁盘 io ，网络排查了吗/

查了，也没问题，磁盘方面用的是 ssd ，当时的 io 不高，网络方面也看了 没发现啥问题