Ghost 发布与交付机制全解析从每日持续部署到每周公共版本的工作流【免费下载链接】GhostIndependent technology for modern publishing, memberships, subscriptions and newsletters.项目地址: https://gitcode.com/GitHub_Trending/gh/Ghost本文以 Ghost 官方仓库的 docs/contributing/shipping.md 为骨架结合.github/workflows、scripts/release.js 等源码细节系统讲解 Ghost 如何围绕main分支构建一套始终绿色、随时可发的多通道发布体系Admin 与公共前端应用走持续交付、公共 Ghost 版本每周二定时发布、Docker 官方镜像随后跟进而非同时上线。读完你将完整掌握 Ghost 的版本节奏、发布触发条件、npm 发布链路、jsDelivr 分发机制以及 Ghost-CLI 安装校验与 Docker 官方镜像更新延迟背后的工程取舍。一图看懂各发布通道的节奏Ghost 将代码进main与发布到用户解耦成多个独立通道。核心原则是main永远是绿色可用状态Admin管理后台与服务端Server的改动必须保持向前/向后兼容不能假设两者会随同一个版本一起上线因为各通道的发布节奏不同发布通道当前节奏Admin仅 Ghost(Pro)每次推送到main的提交在其 Admin 发布路径检查通过后即发布上线Portal 等公共前端应用每当其在main上发生变更时Admin Server公共发布每周二发布一次Admin ServerDocker 官方镜像跟随公共发布经 Docker 团队审核后另行发布Server仅 Ghost(Pro)工作日的每日滚动部署从仓库证据看这个节奏由 .github/workflows/release.yml 的cron: 0 15 * * 2每周二 15:00 UTC触发公共发布而 Admin/Server 的 Pro 通道则由 .github/workflows/ci.yml 中的trigger_cdjob 通过repository-dispatch把产物转发给部署平台完成。Admin随每次提交持续交付Continuous DeliveryAdmin 管理后台在 Ghost(Pro) 上采用持续交付每个推送到main的提交都会构建一个新的 Admin 产物该构建必须通过 Admin 自身的构建检查以及发布路径Docker 镜像构建等相关检查检查全部通过后新版本即生效这要求 Admin 的任何改动都不能假设服务端已具备新能力必须兼容仍运行旧版 Server 的站点。在代码层面.github/workflows/ci.yml 的job_admin-tests会对 Admin 跑 Chrome 下的完整测试pnpm nx run ghost-admin:test随后job_build_admin产出 Admin 构建最终由trigger_cdjob 仅在main/tag/PR 场景下向部署端发起repository-dispatch携带admin_artifact_id供 CD 侧拉取。与此同时为了不让自托管用户的管理体验落后于 Pro公共 Ghost 发行版内会打包一个 Ghost Admin 构建保证ghost install/ghost update装出来的版本自带与其配套的 Admin。Portal 等公共前端应用变更即发 patchPortal、搜索、评论、订阅表单等面向站点访问者的公共应用是一组通过 jsDelivr CDN 分发的 npm 包。官方文档列出的清单为tryghost/portaltryghost/sodo-searchtryghost/comments-uitryghost/signup-formtryghost/announcement-bartryghost/admin-toolbar完整清单以 JSON 形式维护在 scripts/public-apps.json每条记录声明了packageNamenpm 包名、path仓库内目录与configKey服务端配置键如portal、comments。分发模型的关键在于版本线version line当某个应用在main上发生变化时CI 会自动发布一个新的 patch 版本到 npm并清空 jsDelivr 的 CDN 缓存站点实际加载的是 Ghost 服务端配置锁定的major/minor 线内的最新 patch。这一点可在 ghost/core/core/shared/config/defaults.json 中看到直接证据——各应用资源 URL 形如https://cdn.jsdelivr.net/ghost/portal~{version}/umd/portal.min.js~tilde range语义正是patch 自动上浮、major/minor 锁定因此patch 版本可以不经过 Ghost 发行版就直接对全部站点生效前提是该站点已升级到承载对应版本线的 Ghost 版本。CI 中公共应用发布的具体实现.github/workflows/ci.yml 的publish_public_appsjob 是这个机制的落地实现关键设计点包括仅在 push 到main时触发从不在pull_request上运行——避免把id-token: write权限暴露给 PR 可控代码发布的 app 矩阵由 Setup job 通过 scripts/build-public-apps-matrix.js 基于受影响项目计算得出publish_public_apps_matrix每个包用独立的concurrency组串行发布防止两个紧邻的main合并并发计算出相同的 next-patch 号而在 npm 上冲突具体发布版本号由 scripts/compute-next-app-version.cjs 以npm 已发布版本为准计算取当前 major/minor 线上已发布的最大 patch 1或新开版本线时用package.json的精确版本版本号在构建前写回package.json保证打进产物例如 Portal 的REACT_APP_VERSION的版本与发布版本一致通过 npm 的OIDC trusted publishingpnpm publish --access public --provenance --no-git-checks发布不依赖存储的令牌发布后用gacts/purge-jsdelivr-cache按cdn_paths清缓存。minor/major 发布则完全不同它改变的是 Ghost 所锁定的版本线。新版本线只有在它被包含进某次公共 Ghost 发行版、且站点随之升级后才会成为这些站点的默认加载版本。每个应用仓库的 README 中描述有其独立的版本线发布流程。公共 Ghost 发行版每周二自动化的例行发布官方文档明确一个自动化工作流会在每个周二发布一个新的公共 Ghost 版本。对应的 .github/workflows/release.yml 在schedule中声明了cron: 0 15 * * 2每周二 15:00 UTC也支持通过workflow_dispatch手动触发输入项包括bump-type版本提升类型可选auto默认、patch、minorskip-checks是否跳过对 CI 状态的轮询验证dry-run只做版本提升计算与本地提交不推送packages-only仅消费 changesets 提升各 workspace 包版本不提升 Ghost 自身版本、不打 tag、不发布发布需另行运行 Publish Packages 工作流。工作流内部以 SSH deploy key 检出main再执行 scripts/release.js。这个脚本完整刻画了 Ghost 一次发布的决策逻辑值得逐段拆解1. 自动判定版本号迁移与 feature commit 决定 patch/minordetectBumpType()在bumpType为auto时进行两步启发式检测新增数据库迁移对ghost/core/core/server/data/migrations/versions/目录做git diff --diff-filterA若出现core/子目录下的新增迁移文件判定需要minor提升数据库结构变更需要更大的版本语义Feature commit扫描 base tag 到 HEAD 的提交信息凡包含✨、或:sparkles:表情前缀的提交被视为新功能同样提升为minor两者都不命中则默认patch。最终新版本号由semver.inc(currentVersion, resolvedBumpType)计算其中当前版本读取自 ghost/core/package.json脚本还会用git ls-remote校验远程不存在v{newVersion}标签避免重复发布。2. 等 CI 全绿轮询汇总门禁并处理发布被合并超越release.js通过 GitHub API 轮询名为All required tests passed or skipped的汇总 checkwaitForChecks()。两个值得注意的边界处理合并竞态等待期间若main前进了新提交CI 的按分支concurrency会取消正在观察的运行——脚本检测到分支 head 变化后会对新 head 做 fast-forward 重置并重新规划发布planRelease会基于新树重跑版本决策超时与失败最长等待 60 分钟每 30 秒轮询一次若汇总 check 以失败/取消结束且分支未移动则中止并提示重跑 CI。3. 更新主题子模块、统一提升版本并打 tag对main分支的发布脚本会先更新两个默认主题子模块Casper 与 Source分别位于 ghost/core/content/themes/casper 与 ghost/core/content/themes/source将它们签到各自最新的稳定 tag。随后把ghost/core/package.json与apps/ember-admin/package.json的版本同步提升到同一新版本号保证Admin Server作为一个公共发布共同前进通过pnpm version -r消费.changeset/中的变更集把 koenig、packages 等可发布 workspace 包的版本一起定稿并重写依赖区间一次性git add -A后提交v{version}并打同名 tag推送分支与 tag推进到下个 RC将两个包版本写为{nextPatch}-rc.0并再提交一次——main平时始终处于-rc.0的预发布版本态直到下一轮发布消费它。4. 版本标签驱动发布流水线.github/workflows/ci.yml 中对 push 事件的触发分支做了精心设计main、v[0-9].*release 分支、[0-9].x历史大版本维护分支都会触发完整 CI而v[0-9]*版本标签则额外触发发布作业链。官方文档将其概括为版本标签会启动ci.yml中的发布作业CI 依次完成——用 Ghost-CLI 构建并测试ghostnpm 包job_ghost-cli安装ghost-clilatest并针对 npm 实际发布的同一 tarball 做安装冒烟验证将该包发布到 npmpublish_ghostjob仅运行于refs/tags/v*依赖id-token: write用 npm v11 的 OIDC trusted publishing 执行npm publish ghost-*-npm.tgz --access public --provenance无仓库 checkout、无存储令牌创建 GitHub Release 与发布说明create_github_release解析上一个稳定 tag调用 scripts/lib/release-notes.js 生成 notes并附上ghost-*.tgz归档便于无 npm 客户端安装启动 Docker Official Image 的更新流程trigger_docker_library_update以ghost-version-publish事件 dispatch 给镜像维护仓库。ci.yml 的环境设定还透露了当前仓库的运行时基线Node.js 22.23.1单元/验收测试矩阵同时覆盖 24.20.0并在 CI 中关闭了 Nx 的原生命令执行器与 v8-compile-cache以规避上游间歇性崩溃详见 ci.yml 顶部的env注释。Ghost-CLI校验和发布、而非消费源码 ZIP理解 Ghost 的发布还须弄清安装端如何取包。Ghost 的官方安装器 Ghost-CLI 的行为如下常规的ghost install/ghost update会从npm 下载ghost包并校验其公开发布的checksum校验和它不使用 GitHub 生成的源码 ZIP即使 GitHub Release 页面同时提供了 zip/tgz 附件若本地已有构建产物Ghost-CLI 也支持通过--archive选项传入本地的.zip、.tgz或.tar.gz安装——适合测试 CI 构建产物但这不是常规发布路径。这与上面的流水线互为印证真正官方的软件包产物是 npm 上带校验和的 tarball而 GitHub Release 上附带归档只是为了方便不使用 npm 客户端的用户直接下载安装。Docker Official Image独立审核带来的时间差公共 npm 包发布完成后Docker 官方镜像并不自动出现而是走一条跨仓库、需第三方审核的链路TryGhost/docker-library-ghost仓库维护方收到ghost-version-publish事件后为新的 Ghost 与 Ghost-CLI 版本更新其 Dockerfile自动化在 docker-library/official-imagesDocker 官方镜像的中央清单仓库中开启一个拉取请求必须由 Docker Official Images 的维护者批准并合并该 PRDocker 官方 CI 随后构建并发布ghost官方镜像到 Docker Hub。官方文档特别强调了一个现实后果批准权在 Docker 团队而非 Ghost 团队因此Docker 官方镜像的上线时间可能晚于 npm 与 GitHub Release。如果你的运维排期依赖ghost官方镜像需要把这段审核延迟计入计划。Ghost(Pro) Server面向工作日的每日滚动部署把持续交付从 Admin 扩展到 Server 是 Ghost 正在推进的方向。当前状态是最新 Ghost 服务端版本在工作日的每一天滚动部署到 Ghost(Pro)团队正在调研在近期推出面向公众的 nightly 构建版本。这意味着对平台方而言昨日代码今日上线已成为常态而main始终绿色、Admin/Server 相互兼容的纪律正是支撑这一节奏的前提。结语一套多通道、各就其位的发布哲学把 shipping 文档与仓库实现放在一起看Ghost 的发布体系可以归纳为三条清晰原则能快则快Admin、公共应用的 patch、Pro Server 都追求合入即上线把价值交付周期压缩到分钟级公共发行保持节律每周二自动化的 patch/minor 发布由迁移检测与 feature commit 驱动配以等 CI、统一打 tag、推进 RC的严谨脚本保证任何main上的状态都可复现地变成稳定版渠道差异显式化npm 包是权威产物带校验和、走 OIDC provenanceGitHub Release 仅是辅助归档Docker 官方镜像因为外部审核天然滞后——使用方据此安排升级与验收即可。对自托管用户理解这条链路最有价值的落点是升级 Docker 官方镜像前留意其发布滞后对开发者scripts/release.js、.github/workflows/ci.yml 与 .github/workflows/release.yml 则是学习多通道 CI/CD 发布自动化工程实践的一手范本。【免费下载链接】GhostIndependent technology for modern publishing, memberships, subscriptions and newsletters.项目地址: https://gitcode.com/GitHub_Trending/gh/Ghost创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考