Pagure 介绍与选型指南

Pagure 介绍与选型指南：以 git 为中心的开源代码托管平台认知篇，涵盖官方溯源的定位沿革、Flask+pygit2+gitolite3 架构、功能特性、部署路径、适用限制，并与 GitLab CE、Gitea、Forgejo 做版本节奏与资源口径的量化对比，全部数据标注来源与查询日期。

Pagure版本控制代码审查DevOps工程2026/10/28

Pagure 介绍与选型指南

目标：为「是否选用 Pagure 作为自托管 Git 代码托管与协作平台」提供认知与选型依据。本篇为认知篇，全部事实来自官方站点、官方文档与项目仓库的联网溯源，每项关键数据均标注来源与查询日期（统一查询日期 2026-10-28）；本地实测的安装、配置与运维操作不在本篇展开，见 《Pagure 5.14.1 Ubuntu 22.04 安装指南》、《Pagure 5.14.1 配置参数详解》 与 《Pagure 5.14.1 常用 CLI 与运维命令详解》。

一、环境信息

本篇为纯联网溯源的认知类文档，不涉及本地实测环境，信息检索环境如下：

  • 检索执行日期：2026-10-28（所有「查询日期」均指该日）
  • 检索渠道：
    • Pagure 官方项目页与官方文档：https://pagure.io/pagure、https://docs.pagure.org/pagure
    • Pagure 官方 git 仓库 tags：https://pagure.io/pagure.git（git ls-remote 实查最新 tag）
    • Fedora 社区博客与官方讨论区：https://communityblog.fedoraproject.org、https://discussion.fedoraproject.org
    • Forgejo 官方博客：https://forgejo.org
    • GitLab 官方安装要求：https://docs.gitlab.com/ee/install/requirements.html
    • Gitea 官方文档：https://docs.gitea.com/installation/install-from-binary
  • 对比对象的版本与活跃度数据取自各项目官方发布渠道（GitLab tags atom、Gitea 官方发布页、Forgejo 官方发布页、GitHub 同步仓库页面），并经代理网络实查，与本文同日完成。
  • 本组件其余三篇实测文档的环境为 Ubuntu 22.04.5 LTS（x86_64），实测日期同为 2026-10-28。

💡 说明：溯源类文档的结论强度取决于来源等级。本篇引用的均为一手来源（项目官方仓库、官方文档、官方社区博客），对无法一手验证的信息（如社区口碑）不做断言，仅在选型建议中给出定性判断并说明依据。

二、软件概述

2.1 定位

Pagure 是一个「以 git 为中心的代码协作平台（git-centered forge）」，基于 Python 与 pygit2 构建（来源：官方项目页自述，docs.pagure.org/pagure，查询日期 2026-10-28）。官方对它的定位描述为：托管项目及其文档、通过工单系统收集问题与增强请求、允许用户 fork 项目并通过 pull-request 机制贡献代码——即一套完整的开源代码托管与协作能力，与 GitHub/GitLab 在功能形态上同类，但强调「从架构到部署都可以完全自主可控」。

Pagure 由 Fedora 社区打造并长期作为 Fedora 项目的官方代码托管与协作平台使用，其典型部署规模是整个 Linux 发行版的源码包与基础设施仓库托管，这在同类自托管 forge 中是独一份的工程背景（来源：Fedora 社区博客与官方讨论区，查询日期 2026-10-28，详见 2.3 与 6.3）。

2.2 名称由来

「Pagure」一名取自法语单词 pagure，是寄居蟹总科（Paguroidea，即寄居蟹类甲壳动物）在法语中的俗名（来源：官方文档「About its name」小节，docs.pagure.org/pagure，查询日期 2026-10-28）。官方还录制了作者本人朗读的发音样本，强调法语式的重读 g 音。

2.3 发展沿革

  • 项目由 Pierre-Yves Chibon（社区 ID：pingou）创建并长期维护，官方文档项目页显示「Created 12 years ago」（以查询日 2026-10-28 回推约为 2014 年前后立项）、「Releases 142」（来源：docs.pagure.org/pagure 页面，查询日期 2026-10-28）。
  • Pagure 长期是 Fedora 项目的基础设施核心：Fedora 的代码托管（含 rpm 源码包的 dist-git 工作流）与议题协作均运行在 Pagure 之上（来源：Fedora 社区博客《The forge is our new home》对 pagure.io 历史作用的回顾，查询日期 2026-10-28）。
  • 2024 年 12 月，Fedora 决定将代码与议题托管从自研的 Pagure 迁移至 Forgejo（来源：Forgejo 官方 v13.0 发布博文对这一决定的引用，forgejo.org/2025-10-release-v13-0/，查询日期 2026-10-28）；Fedora 社区博客随后宣布「retire our homegrown forge」，最终切换计划在 Flock to Fedora 2026 大会前后完成（来源：communityblog.fedoraproject.org/the-forge-is-our-new-home/，查询日期 2026-10-28）。Fedora Release Engineering 团队也已公告进入从 Pagure 迁移到 Forgejo 的最终阶段（来源：discussion.fedoraproject.org 官方帖，查询日期 2026-10-28）。
  • 上游最新版本为 5.14.1，tag 日期 2024-05-24（来源：官方 git 仓库 git ls-remote https://pagure.io/pagure.git tags 实查，查询日期 2026-10-28）；官方项目页顶部已标注「MOVED TO forge.fedoraproject.org」（查询日期 2026-10-28）。

⚠️ 注意：2024-05 之后上游无新版本发布，官方社区已转入 Forgejo 迁移通道，这是本文档集所有选型建议的核心背景。Pagure 仍可自托管使用（本文档集 5.14.1 实测可完整跑通），但选型前必须清楚其上游维护状态。

2.4 维护与上游现状

综合官方信息（查询日期 2026-10-28）：pagure.io 站点已处于日落收尾阶段，项目文档页不再以活跃社区形态运营（页面标注维护者为创建者本人、项目已移至 Fedora 新 forge 域名下）；软件本体 5.14.1 仍是最新 tag；Fedora 官方对 Pagure 的定性是「自研 forge 退役、迁移到 Forgejo」。对使用者而言，这意味着：现有部署可继续运行，问题类求助更多依赖社区既有文档与源码阅读，而非活跃的上游支持通道。

三、核心架构

3.1 技术栈

Pagure 的技术栈组合（来源：官方文档与 requirements 依赖清单，docs.pagure.org/pagure，查询日期 2026-10-28；栈内各组件的协同方式另经 Ubuntu 22.04.5 LTS 实测验证，见安装指南篇）：

  • Web 框架：Python + Flask，模板渲染服务端页面
  • git 操作库：pygit2（libgit2 的 Python 绑定），直接读写 git 仓库；官方明确要求 pygit2 版本与系统 libgit2 版本对齐（官方 README 手工部署段：「pip install pygit2==<version of libgit2 found>.*」）
  • 数据库：PostgreSQL（生产）/ SQLite（开发）
  • 任务队列：Celery + Redis（webhook 派发、邮件、仓库同步等异步任务）
  • SSH 授权：gitolite3（git 协议与 SSH 推送的访问控制）
  • 文档与元数据：议题、文档、PR 均以独立 git 仓库形态存储（见 3.3）

3.2 服务组件

一次完整的生产部署通常包含以下进程角色（角色划分与官方文档的部署模型一致）：

角色说明
pagure-webFlask/gunicorn Web 应用，承载页面与 REST API
pagure-workerCelery worker，处理异步任务（hook 派发、通知、远端仓库同步类任务等）
PostgreSQL项目、用户、议题、PR 等结构化数据
RedisCelery 消息代理与事件源（EventSource）支撑
gitolite3 + git 用户SSH 通道授权与仓库 ACL 编译
Nginx（可选）反向代理与访问日志

💡 技术拓展：git 托管平台的 SSH 授权实现不止 gitolite3 一种。常见方案对比——

方案原理/特点适用场景
gitolite3独立授权层，conf 文件声明仓库权限，keydir 管理公钥传统精细 ACL、可审计配置
内置实现平台自研 authorized_keys/内置 SSH 服务直接接管Gitea/Forgejo/GitLab 采用，免装外部组件
git-daemon仅匿名只读 git:// 协议公开仓库只读分发

Pagure 实际采用 gitolite3（配置键 GIT_AUTH_BACKEND = 'gitolite3'），把 SSH 命令交给 gitolite-shell 处理，这带来最细粒度的仓库级 ACL，但也增加了部署组件与排查链路长度。

3.3 多仓库存储模型

Pagure 的一个显著设计是「一个项目 = 一组 git 仓库」：除主代码仓库外，议题（tickets/issues）、文档（docs）、PR（requests）各自都是独立的 git 仓库。官方 README 手工部署段落要求一次性创建「projects, forks, docs, requests and tickets' git repo」的目录结构，即是该模型的直接体现（来源：docs.pagure.org/pagure，查询日期 2026-10-28）。

这一设计的直接收益是议题与 PR 的全部内容（正文、评论变更）天然具备版本历史与离线可迁移性；代价是磁盘上仓库数量成倍增长，备份与巡检需覆盖整组目录（备份与恢复的实测做法见运维命令篇第四章）。

3.4 SSH 授权链

SSH 推送链路为：客户端 → git 用户（gitolite-shell）→ gitolite3 ACL 判定 → 仓库 + Pagure 服务端钩子（hookrunner）。公钥管理与 authorized_keys 生成由 Pagure 写入 gitolite 管理仓库（keydir），再由 gitolite 编译生效（来源：官方文档 gitolite 配置章节；全链路实测过程见安装指南篇与运维命令篇）。

四、功能特性

以下功能清单以官方文档与官方 README 的明示内容为准（来源：docs.pagure.org/pagure，查询日期 2026-10-28），并标注可在本平台其余三篇中验证的部分。

4.1 代码托管与协作

  • git 仓库托管、fork、pull-request（官方 README 自述的三大核心能力）；
  • 分支管理、标签、发布文件（releases）目录；
  • 项目可设私有（配置键 PRIVATE_PROJECTS）与只读锁定（read-only 标志）。

4.2 议题与文档

  • 议题/工单系统：bug 报告与增强请求，支持标签、优先级、里程碑等元数据（官方 README：「report issues or request enhancements using the ticketing system」）；
  • 项目文档托管：每个项目可挂独立文档站点（配置键 DOC_APP_URL 指向文档服务）。

4.3 权限组与 API

  • 群组（group）管理：按组授予项目权限，配合管理员组（ADMIN_GROUP）做平台级管理；
  • REST API + 令牌（token）体系：API 令牌按 ACL 细分权限，覆盖议题、PR、仓库操作等接口（运维命令篇 4.6 节实测了令牌 ACL 的刷新与查看）；
  • 管理员 CLI：pagure-admin 提供用户封禁、项目删除、ACL 同步、gitolite 刷新等管理子命令（运维命令篇全量实测）。

4.4 dist-git 与发行版集成

Pagure 支持「主仓库 + 门禁分支」的 dist-git 工作流，Fedora 即用它托管 rpm 源码包并驱动打包协作（来源：Fedora 基础设施公开信息与社区博客回顾，查询日期 2026-10-28）。对希望复刻「发行版级源码包管理」流程的团队，这是 Pagure 相对其他 forge 的差异化能力。

4.5 扩展机制

  • 服务端钩子（hook）体系：pre-receive/post-receive 等钩子由统一入口 hookrunner 派发，官方与自定义插件通过该机制接入；
  • Webhook 与 Fedmsg/Fedora 消息总线通知（配置键 WEBHOOK、FEDMSG_NOTIFICATIONS）；
  • 插件化项目开关：issue tracker、docs、PR 等能力可按项目启停（ENABLE_TICKETS、ENABLE_DOCS）。

五、快速开始

5.1 官方部署路径概览

官方 README 给出三类启动方式：开发环境脚本、Vagrant 虚拟机、手工部署（来源：docs.pagure.org/pagure「Get it running」章节，查询日期 2026-10-28）。面向真实服务器的是手工部署路径，官方步骤可归纳为六步：

  1. 安装系统级依赖（git、python3、libgit2 开发库、redis、编译工具链等，Fedora 侧 dnf install git python3 python3-devel libgit2-devel redis libjpeg-devel gcc libffi-devel redhat-rpm-config，逐字取自官方 README）；
  2. git clone https://pagure.io/pagure.git 取源码；
  3. 建 Python 虚拟环境，先按系统 libgit2 版本钉住 pygit2（pip install pygit2==<libgit2 版本>.*），再 pip install -r requirements.txt；
  4. 创建 repos/remotes/attachments/releases 等数据目录，复制并编辑 alembic.ini 后执行 python createdb.py --initial alembic.ini 初始化数据库；
  5. 启用并启动 redis（systemctl enable redis + systemctl start redis，逐字取自官方 README）；
  6. 分别运行 ./runworker.py 与 ./runserver.py，访问 http://127.0.0.1:5000 验证。

以上为官方原文给出的最小启动路径，适用于快速验证；它未包含生产所需的 systemd 托管、gitolite3 授权链与反向代理配置。

5.2 Ubuntu 22.04 部署指引

Ubuntu 22.04 侧有两点官方事实需要先知道：其一，官方未提供 deb 软件包与 PPA 安装通道；其二，PyPI 上没有 pagure 包，安装必须从 git 源码出发（来源：官方文档安装章节与 PyPI 公开页面，查询日期 2026-10-28）。因此 Ubuntu 上的可行路径即「源码 + 虚拟环境」部署。本文档集已在 Ubuntu 22.04.5 LTS 上完成了从依赖钉版、PostgreSQL/Redis/gitolite3 配置、systemd 托管、Nginx 反代到 SSH 推送端到端验证的完整实测，逐步命令与真实回显见 《Pagure 5.14.1 Ubuntu 22.04 安装指南》。

5.3 最小验证清单

无论何种路径部署，完成后的最小验证清单为：首页 HTTP 200、/api/0/version 返回 API 版本、创建用户并登录、建立项目并完成一次 SSH 推送（各步实测回显见安装指南篇第七章与运维命令篇第四章）。

六、适用场景与限制

6.1 适用场景

  • 希望完全自主掌控代码托管平台技术栈（Python 全栈、无闭源组件）的团队；
  • 需要 dist-git 式「源码包 + 门禁分支」工作流的发行版/软件集合维护组织；
  • 已在 Fedora 生态内、希望与 Fedora 工作流保持一致的基础设施团队；
  • 对 gitolite3 细粒度 ACL 有明确需求、愿意承担多组件部署复杂度的环境。

6.2 已知限制

  • 上游自 2024-05（5.14.1）后未再发版，无新特性与官方安全补丁节奏（来源：官方 git 仓库 tags 实查，查询日期 2026-10-28）；
  • 无官方 deb/RPM 之外的现代化分发渠道（PyPI 无包），升级需自行跟踪 git 主干；
  • 部署组件多（web/worker/PostgreSQL/Redis/gitolite3），相比单二进制方案运维面更宽；
  • 部分管理命令存在版本缺陷（如 5.14.1 的 pagure-admin refresh-ssh 需应用上下文变通，实测记录见运维命令篇 4.5 节）。

6.3 迁移与风险提示

Fedora 已官方决定从 Pagure 迁移至 Forgejo，并把最终切换定在 Flock to Fedora 2026 前后（来源见 2.3）；Forgejo 官方提供了从 Pagure 迁移仓库的能力（来源：forgejo.org v13.0 发布博文，查询日期 2026-10-28）。选型 Pagure 的团队应同步规划退出路径：优先在选型期评估 Forgejo/Gitea 的仓库迁移接口，避免数据长期锁定在维护放缓的上游。

七、同类选型对比

7.1 对比总表

四个主流可自托管 forge 的量化对比（各列数据来源与查询日期见 7.2/7.3 的分项说明；「—」表示该项未公开对应口径数据）：

维度Pagure 5.14.1GitLab CE 19.5.2Gitea 28.2.0Forgejo 17.0.1
最新版本 / 日期5.14.1 / 2024-05-2419.5.2 / 2026-10-2728.2.0 / 2026-10-1817.0.1 / 2026-10-26
开发语言 / 技术栈Python（Flask + pygit2）Ruby on Rails + Go 组件Go（单二进制）Go（单二进制，Gitea 分支）
许可证GPLv2+MIT（开源核心 + 商业版双轨）MITMIT
数据库PostgreSQL（生产）/SQLite（开发）PostgreSQL（唯一支持）SQLite / MySQL / PostgreSQL 内置支持SQLite / MySQL / PostgreSQL 内置支持
SSH 授权gitolite3 外置内置内置内置
官方资源口径—（无官方量化要求）1000 用户/20 req/s 需 8 vCPU + 16 GB，最低约 8 GB 可运行轻：单二进制 + Git ≥ 2.0，支持树莓派级 arm64 设备与 Gitea 同源同量级
社区活跃度（星标）GitHub 同步仓库 228 stars，上游 2024-05 后无发版—（主仓库自托管于 GitLab.com）GitHub 约 59k starsCodeberg 主仓库 5731 stars
背景组织Fedora 社区GitLab Inc.Gitea 社区Codeberg e.V.（非营利）
2026-10 现状Fedora 官方宣布退役并迁移 Forgejo活跃，月度发版活跃活跃，承接 Fedora 迁移

7.2 版本节奏与维护状态量化

以查询日期 2026-10-28 为基准的版本数据（各来源均为官方发布渠道当日实查）：GitLab CE 已到 v19.5.2（tags atom，2026-10-27）且保持高频月度发版；Gitea v28.2.0 发布于 2026-10-18；Forgejo v17.0.1 发布于 2026-10-26；Pagure 最新 tag 5.14.1 发布于 2024-05-24，距今约两年五个月无新版本。版本节奏是判断 forge 类平台维护健康度最直接的量化指标——GitLab/Gitea/Forgejo 均在最近十日内有发布，Pagure 的发布间隔已达年量级。

7.3 资源占用与部署复杂度

  • GitLab CE 官方安装要求：面向最多 20 请求/秒或 1000 用户需 8 vCPU + 16 GB 内存，内存受限场景最低约 8 GB 可运行；Linux 包安装本体约需 2.5 GB 存储；PostgreSQL 为唯一支持数据库（来源：docs.gitlab.com/ee/install/requirements.html，查询日期 2026-10-28）。
  • Gitea 官方二进制部署文档：单二进制内嵌资产与 SQLite/MySQL/PostgreSQL 三种数据库支持，硬性依赖仅 Git ≥ 2.0，提供 arm64 等面向树莓派 4 级设备的构建（来源：docs.gitea.com/installation/install-from-binary，查询日期 2026-10-28）。
  • Forgejo 与 Gitea 同源，部署形态同为单二进制（来源：forgejo.org 官方站点对自身定位的描述，查询日期 2026-10-28）。
  • Pagure 无官方量化资源口径；按技术栈推算介于两者之间（Python 多进程 + 独立 gitolite3），本平台安装指南篇在 2 vCPU/4 GB 级实例上完成了全组件实测，可作为小型部署的资源参考。

关键差异：单二进制方案（Gitea/Forgejo）把「部署面」压到最低；GitLab 用资源换全家桶功能；Pagure 的组件面与 GitLab 相近但功能面小得多，资源口径却缺乏官方文档，属于「部署成本与文档完备度不成比例」的组合。

7.4 功能与工作流差异

  • 功能广度：GitLab 内置 CI/CD、软件制品仓库、安全扫描等平台级能力；Gitea/Forgejo 内置轻量 CI（Actions/runner）；Pagure 无内置 CI，需经 webhook/hook 机制外接。
  • 权限模型：Pagure 依赖 gitolite3 提供仓库级 ACL 文件（可版本化审计），其余三家为应用内置权限体系。
  • 工作流特色：Pagure 的 dist-git 门禁分支模型在发行版源码包场景独有；GitLab 优势在一体化 DevOps；Gitea/Forgejo 优势在轻量与低维护成本。
  • 迁移性：Forgejo 官方支持从 Pagure 迁移仓库（来源：forgejo.org v13.0 博文，查询日期 2026-10-28）；Gitea 与 Forgejo 互为分支、仓库格式兼容度高；GitLab 提供各平台通用导入器。

7.5 选型建议

  • 新建自托管代码平台、无 Fedora/dist-git 诉求：优先 Gitea 或 Forgejo（轻量、活跃、迁移通道清晰）；二者之间按治理偏好取舍（Forgejo 由非营利协会治理且承接了 Fedora 官方迁移）。
  • 需要一体化 CI/CD 且资源预算充足：GitLab CE。
  • 明确需要 dist-git 工作流或 Python 全栈自主可控、且能接受上游放缓与自担运维：可选 Pagure，并按安装指南篇的实测路径落地；同时按 6.3 规划向 Forgejo 的迁移预案。
  • 已在运行 Pagure 的存量环境：保持 5.14.1 稳定运行（配置与运维见配置篇与命令篇），把升级窗口留给迁移评估而非等待上游新版本。

八、参考链接