OpenDisplay 发布自动化Conventional Commits 加 release-please 自动生成版本的完整指南【免费下载链接】opendisplayFree, open-source Sidecar/Duet alternative — use your iPhone, iPad or Mac as a true second monitor for your primary Mac over USB or WiFi. Low latency H.264, Retina HiDPI, touch input.项目地址: https://gitcode.com/GitHub_Trending/op/opendisplayOpenDisplay 是一款免费的开源「副屏 / 虚拟显示器」工具它把闲置的 iPhone、iPad 或 Mac 通过 USB 或 Wi-Fi 变成 Mac 的第二块显示器是 Apple Sidecar、Duet Display 的自托管替代方案支持 Retina 高清与触控输入。本文带你完整看懂它的发布自动化流水线如何用 Conventional Commits 规范 release-please 自动判断版本号、打标签、生成 Changelog再自动构建、公证并分发双平台应用——全程零人工干预。为什么副屏应用也需要「一键发布」OpenDisplay 是双平台应用Mac 端macOS 14和 iOS 端App Store / TestFlight。每次版本迭代都要走完整链路生成 Xcode 工程、签名构建、公证notarize、打包 DMG、上传发布、更新自动更新源。如果手动操作任何一步出错都可能让发布卡住。这套流水线的核心思路只有一句话人只负责合并代码机器负责其余一切。核心文件如下文件职责.github/workflows/release.yml发布主流水线判断版本、构建、上传、生成更新源.github/workflows/pr-title.ymlPR 标题规范检查守门 Conventional Commitsfastlane/Fastfilefastlane 通道签名、公证、打 DMG、传 TestFlightfastlane/Matchfile证书与描述文件管理配置CHANGELOG.md自动生成的版本日志人工永不手改第一道关卡PR 标题强制 Conventional Commits自动化能否成立取决于提交信息是否规范。OpenDisplay 采用 squash-merge 合并方式PR 标题就是提交信息而 release-please 正是靠解析这些类型来决定版本号怎么升。仓库专门配置了 pr-title.yml 工作流每次 PR 打开或改标题时都会运行非规范标题直接打回。它允许 11 种标准类型feat新功能、fix修复、perf性能优化refactor重构、docs文档、test测试build构建、ci持续集成、chore杂务、style样式、revert回滚这个检查不是「最好有」而是「必须有」。配置文件里的注释还记录了一次真实教训某个 PR 标题不规范导致功能发布时漏写 Changelog、版本号只升了补丁位直到人工阅读发布内容才发现——一次疏忽整个版本日志都受影响所以才把它做成硬性关卡。核心引擎release-please 自动决定版本号真正的主角是 release.yml 工作流它在推送 main 分支时触发第一步就是运行 release-please 动作release-type: simple。它的工作原理非常直观扫描上两个 tag 之间的所有 Conventional Commits 提交决策出现feat就升 minor如 1.18.0 → 1.19.0只有fix/chore就升 patch执行自动打 tag、创建 Release、写入 CHANGELOG.md 并回推打开项目里的 CHANGELOG.md 就能看到成果每个版本都有日期、特性/修复分类、PR 编号与提交哈希全部机器生成。一个容易被忽略的细节是并发锁流水线设置了concurrency组且永不取消运行中的任务。原因是两次快速合并可能同时触发两次发布而发布任务可能正处于上传 TestFlight 的关键时刻中途取消会造成脏状态。对新手来说这是很好的工程范例——自动化不仅要跑得快还要跑得稳。从 tag 到安装包fastlane 自动构建公证release-please 打出 tag 后build-ios和build-mac两个任务才会启动release_created true时才执行它们都由 fastlane 驱动具体定义在 Fastfile 中ios beta签名后构建 iOS 应用并自动上传 TestFlightmac build_release构建 Developer ID 签名并公证的主应用产出OpenDisplay.dmgmac build_receiver_release同款流水线产出独立的OpenDisplay Receiver应用——把另一台闲置 Mac 也变成显示器两个版本号都来自同一次发布营销版本号取 tag 名去掉v前缀构建号直接用 CI 运行序号保证每次构建号单调递增。构建完成后DMG 会被gh release upload挂到该 tag 的 Release 页面上用户直接下载。额外一步自动生成 Sparkle 自动更新源macOS 用户最在意的是「装完还能不能自动更新」。OpenDisplay 的答案在发布流水线的最后一步用 Sparkle 的官方工具为两个 Mac 应用分别生成appcast.xml与appcast-receiver.xml签名后提交到public/目录如 public/appcast.xml。这个目录变更会再次触发 pages.yml 工作流重新部署项目站点更新源即刻生效。整条链是合并代码 → 自动定版本 → 自动公证分发 → 自动更新源 → 用户 App 内点「检查更新」更贴心的是如果维护者还没配置 Sparkle 签名密钥这一步会优雅跳过而不是让发布失败——自动化的容错设计同样值得学习。新手能直接抄的三个实践标题即契约把 Conventional Commits 做成 CI 硬性检查参考 pr-title.yml从源头保证版本日志可靠让工具决定版本号不要手动改版本号让 release-please 根据提交类型自动升降参考 release.yml 的release-please步骤发布即分发fastlane 通道统一封装「签名 → 公证 → 打包 → 上传」一次 tag 触发双平台全流程参考 Fastfile对 OpenDisplay 这样的开源副屏项目来说这套自动化让「发版」从一件需要专人盯守的体力活变成了合并代码后自动完成的例行公事——这正是普通用户能持续快速收到稳定新版本的底层原因。【免费下载链接】opendisplayFree, open-source Sidecar/Duet alternative — use your iPhone, iPad or Mac as a true second monitor for your primary Mac over USB or WiFi. Low latency H.264, Retina HiDPI, touch input.项目地址: https://gitcode.com/GitHub_Trending/op/opendisplay创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考