By Jermine

☰

在开源代码托管平台的选择上，Gitea 凭借轻量、易部署的特性，一直是很多开发团队的首选。但近两年来，Forgejo 的出现和崛起，给这个领域带来了新的变量。

Gitea 和 Forgejo 到底是什么关系？它们的 CI/CD 能力有何差异？如何基于它们搭建现代化的 DevOps 流水线？又能否将 Kubernetes 作为 CI/CD 的执行环境？

这篇文章将基于我们团队的调研和实践，一次性讲清楚这些问题。

一、Gitea 的生态：二次开发与周边工具

在深入对比之前，有必要先了解一下围绕 Gitea 形成的丰富生态。Gitea 不仅是一个代码托管平台，更是一个可以被深度定制和集成的底座。

基于 Gitea 的二次开发主要分为两类：

1. 直接修改核心的"软分叉"

这类项目直接修改了 Gitea 的源代码，以扩展其核心功能或适配特定场景。

  • OpenI 平台：在 Gitea 基础上增加了对社交化协同开发、大数据集存储管理和智能计算平台接入等功能。
  • go-gittisane：为 I2P 网络设计的 Gitea 软分叉，使其能作为 I2P 服务运行。

2. 围绕 API 的周边生态

Gitea 提供了完善的 API，围绕它构建了一个庞大的工具链：

  • 机器人（Bots）：如用于代码检查的 gopher-bot、展示 SonarQube 分析结果的 sq-bot、处理陈旧 Issue 的 staletea 等。
  • 命令行工具（CLI）：官方出品的 tea，以及支持多平台的 gcli、grp 等。
  • DevOps 与 CI/CD 集成：Drone、AppVeyor、Agola 等持续集成服务均内置了对 Gitea 的支持。
  • 其他实用工具：如提供高性能 Pages 服务的 Gitea Pages、终端仪表盘 gitea-dash，以及从 GitHub、Bitbucket 迁移数据的各类工具。

如果你对发现更多此类项目感兴趣，可以搜索 awesome-gitea 仓库，或在 GitHub/Gitea 上直接搜索关键词。

二、Gitea 的主要替代方案

除了在 Gitea 生态内进行二次开发，你也可以考虑其他独立的替代品。这里重点介绍三个方向：

特性 Forgejo Gogs GitLab CE（社区版）
一句话定位 社区驱动的 Gitea 替代品，无缝迁移 极致轻量的 Git 服务器 功能全面的 DevOps 一体化平台
与 Gitea 关系 社区软分叉，现已独立 Gitea 的前身 独立的竞品
核心优势 社区治理、非营利组织运营 资源占用极低，无多余功能 功能全面，集成 CI/CD、安全扫描等
资源占用 非常低（≈200MB） 非常低（比 Gitea 略低） 较高（最低 4GB 内存）
内置 CI/CD 支持（Forgejo Actions） 不支持，需外部集成 支持（GitLab CI/CD）

简单来说：

  • 选 Forgejo：如果你满意 Gitea 的功能，但更看重社区驱动、非营利治理模式。
  • 选 Gogs：如果你的硬件资源极其有限（如老式 NAS），且只需要最基础的 Git 功能。
  • 选 GitLab CE：如果你需要一体化的 DevOps 平台，愿意投入更多服务器资源。

三、核心之争：Forgejo vs Gitea

这是当前很多人纠结的地方。两者目前在日常功能体验上差异不大，但背后的治理哲学截然不同，这决定了它们未来的走向。

关键差异对比

对比维度 Forgejo Gitea
项目起源 2022 年底从 Gitea 分叉而来 2016 年从 Gogs 分叉而来
治理模式 非营利社区驱动（Codeberg e.V.） 商业公司支持（Gitea Ltd.）
核心哲学 社区主导、自由软件优先 商业投资驱动、生态广泛
安全公告 提前向所有人公开 提前通知付费客户
自由软件程度 100% 自由开源 “开放核心” 模式，部分专有
特色方向 ActivityPub 联邦协议、社区自治 更广泛的生态系统和商业集成

如何选择？

  • 选择 Forgejo：如果你认同社区驱动、非营利治理，重视 100% 自由开源和透明的安全流程，或者希望支持去中心化（如 ActivityPub）等未来方向。另外，如果你正在使用或计划使用 Codeberg 平台，Forgejo 是天然之选。
  • 选择 Gitea：如果你偏好商业公司支持，认为其发展更稳定或更快，或者看重更广泛成熟的生态系统和社区熟悉度。如果你对当前的 Gitea 很满意，没有特别的迁移理由，继续使用也完全没问题。

四、CI/CD 深度对比：谁更强？

两者都提供了名为 Actions 的内置 CI/CD 解决方案，语法兼容 GitHub Actions，这意味着你可以复用海量的现有脚本。

1. 设计哲学与开源纯粹性

  • Forgejo：坚持 100% 自由开源。它自己的开发、测试和发布流程，都完全运行在 Forgejo 和 Forgejo Actions 之上，是真正的"自托管"（dogfooding）。
  • Gitea：其开发、测试和发布流程重度依赖 GitHub 和 GitHub Actions。且采用"开放核心"模式，部分非开源代码不在 MIT 许可下发布。

2. 安全与稳定性策略

  • 安全公告：Forgejo 的安全补丁公告对所有人公开透明。而 Gitea 的安全更新预先通知仅面向付费客户。
  • 稳定性测试：Forgejo 特别强调了端到端（end-to-end）和升级测试，主动避免因存储等设置变更导致的回归问题。

3. 实现与 Runner 管理

  • Forgejo：其官方推荐方案是在临时虚拟机（VM）中运行任务，以实现更好的隔离，但可能带来更高的资源消耗和相对较慢的启动速度。
  • Gitea：使用 act_runner 独立程序，同样需要自行搭建和维护。

五、动手实践：搭建自己的 CI/CD 流水线

无论是 Forgejo 还是 Gitea，搭建 CI/CD 流水线的步骤都非常相似：

  1. 部署 Runner：
    • Gitea 使用 act_runner，Forgejo 使用 Forgejo Runner。两者都支持 Docker 部署，可以参考官方文档快速上手。
  2. 编写工作流文件：
    • 在仓库根目录下创建 .forgejo/workflows/ 或 .gitea/workflows/ 文件夹，编写 YAML 格式的工作流文件（如 ci.yml），定义触发条件、作业和步骤。
    • 可以复用大量现有的 GitHub Actions，但 Forgejo 官方表示其目标并非完全兼容，迁移时可能需要进行微调。
  3. 配置与使用：
    • 在仓库设置中管理 Runner、环境变量和 Secrets（用于存放密码、API 密钥等敏感信息）。
    • 完成配置后，每次代码推送或创建 PR，都会自动触发流水线。

六、进阶话题：在 Kubernetes 上运行 Runner

可以。 Forgejo 官方提供了在 Kubernetes 中部署 Runner 的示例和文档。

  • 官方示例：Forgejo 官方仓库的 examples/kubernetes 目录下有完整的部署示例。
  • 版本要求：从 Forgejo Runner 3.0.0 版本开始，其容器镜像采用无 root 权限（rootless）设计，提升了安全性。
  • DinD 支持：如果工作流需要构建容器镜像，通常需要 Docker in Docker（DinD）模式，这要求为 Pod 设置 privileged: true（需评估安全风险）。
  • 高级特性：社区正在探索让 Runner 成为轻量级控制器，在作业触发时动态为每个任务创建独立的 Pod 作为执行环境，避免为不同操作系统维护多个 Runner 镜像。

七、总结与建议

经过以上对比和实践梳理，核心建议如下：

  • 如果追求纯粹的开源自治：Forgejo 是更理想的选择。它在治理、安全透明度和未来去中心化方向上更有吸引力。
  • 如果信赖商业支持与主流生态：Gitea 依然是一个优秀且成熟的选择。

在 CI/CD 方面，两者能力相当，都足以支撑现代化的 DevOps 需求。而是否将 Kubernetes 作为执行环境，Forgejo 给出了官方支持，Gitea 社区也有相应的探索。

希望这篇文章能帮助你理清思路，做出更适合自己团队的技术选型。如果你有任何实践中的问题或经验，欢迎在评论区交流讨论。

相关文章