Dave Page：将 pgAdmin 构建农场迁移至 GitHub Actions
内容提要
pgAdmin 已将构建流程从 Jenkins 迁移至 GitHub Actions，工作流文件存于主仓库，便于审查和恢复。新流程在九种 Linux 发行版上实际安装测试，发现了旧检查无法捕捉的仓库路径错误。容器镜像和 Helm chart 也迁至 GitHub 容器注册表，未来有望构建 arm64 包。
延伸解读
构建流程透明化：从黑盒到可审查
迁移前，Jenkins 的配置存储在数据库中，通过网页界面修改，变更无人审查，且只有少数人了解其连接方式，形成单点故障。迁移后，所有工作流文件位于主仓库的 .github/workflows 目录，作为普通文件出现在拉取请求中，任何贡献者都能阅读和审查构建逻辑。这使构建过程像源代码一样被版本控制、讨论和恢复，降低了因人员变动导致构建中断的风险。
安装测试：发现旧检查遗漏的仓库错误
新的验收测试不再仅检查文件是否存在，而是按照 README 在干净容器中实际安装 pgAdmin，覆盖九种 Linux 发行版，并验证 Windows 安装包签名、macOS 公证及分离签名。这种测试已发现两个旧检查无法捕捉的 bug：软件包发布目录比仓库元数据声称的深一层，以及 noarch RPM 被放在 dnf 客户端不会查找的目录。两者中所有文件、索引和签名都正常，但仓库实际不可用。
容器镜像与 Helm chart 迁移至 GHCR
容器镜像现在同时发布到 GitHub 容器注册表（ghcr.io/pgadmin-org/pgadmin4）和 Docker Hub，标签一致，支持 amd64 和 arm64 架构。Docker Hub 仍是当前官方推荐，因为大量教程和 compose 文件引用它，但项目希望最终以 GHCR 为主，因为该注册表由项目而非个人拥有。Helm chart 已完全迁移至 oci://ghcr.io/pgadmin-org/pgadmin4-helm，因其用户群较小，迁移影响更小。
未来可能构建 arm64 包与本地复现 CI
过去只构建 x86_64 Linux 包，因为增加架构需要寻找、配置和维护另一台机器。现在这不再是硬件问题，而是工作流配置问题，因此未来有望构建 arm64 包，但作者未承诺时间表。此外，工作流刻意镜像 make check-* 目标，贡献者若修改 pkg/ 目录，可在本地运行对应目标复现 CI 失败，无需猜测构建服务器的差异。
Q&A
pgAdmin 为什么要把构建流程从 Jenkins 迁移到 GitHub Actions？
因为 Jenkins 构建农场是项目中最不透明的部分：配置存储在数据库中，无法像代码一样被审查和版本控制，且依赖需要维护的物理机器。迁移后，构建流程成为主仓库中的普通文件，可被审查、恢复，并减少了基础设施维护负担。
新的 GitHub Actions 工作流文件放在哪里？大概有多少个？
所有工作流文件都放在主 pgAdmin 仓库的 .github/workflows 目录下，大约有二十多个，覆盖每次提交的构建检查、夜间快照构建、发布候选构建以及候选版本到正式发布的晋升。
新的验收测试是如何模拟用户安装的？它发现了什么旧检查无法捕捉的问题？
验收测试在干净的容器中按照仓库 README 的说明，像用户一样添加 APT 或 YUM 仓库并安装 pgAdmin，不绕过任何验证。它发现了两个旧检查无法捕捉的 bug：软件包发布在比仓库元数据声称的更深一层目录，以及 noarch RPM 被放在 dnf 客户端不会查找的目录中。
容器镜像和 Helm chart 现在发布到哪里？有什么变化？
容器镜像发布到 GitHub 容器注册表 ghcr.io/pgadmin-org/pgadmin4，同时保留 Docker Hub，两者标签相同，支持 amd64 和 arm64 架构。Helm chart 则完全迁移到 oci://ghcr.io/pgadmin-org/pgadmin4-helm。
迁移后，贡献者修改打包相关代码时有什么便利？
贡献者可以在主仓库中直接阅读将用于构建的工作流文件，审查者也能看到。工作流刻意镜像了 make check-* 目标，因此本地复现 CI 失败只需找到对应的目标，而不用猜测构建服务器的行为。
Windows 和 macOS 包捆绑的 Python 版本现在如何管理？
Python 解释器版本现在固定在仓库中的 pkg/python-version.txt 文件里，两个平台在构建时下载该确切版本，而不是使用构建机上碰巧安装的版本。升级 Python 需要提交一个 commit 并经过审查。Linux 包不受影响，继续使用发行版自带的 Python。
哪些构建环节仍然需要自托管运行器？为什么？
Windows 安装程序签名需要硬件令牌上的证书，必须连接物理机；macOS 包签名和公证需要从加密秘密中获取 Apple 凭据；发布到下载站点需要 SSH 密钥，这些密钥存放在一台只能通过固定动词列表访问的自托管运行器上。这些环节无法在托管运行器上完成。
迁移到 GitHub Actions 后，未来构建 arm64 Linux 包的前景如何？
以前从未构建过 x86_64 以外的 Linux 包，因为增加架构需要寻找、配置和维护另一台机器。现在这不再是硬件采购问题，而是工作流配置问题，因此 arm64 包在技术上是可行的，尽管没有承诺具体时间表。
