尧图网络科技YAOTU DIGITAL 获取报价
获取报价
首页 / 资讯中心 / 文章详情

CodeBurn 发布全流程指南:CLI、macOS 菜单栏与 Electron 桌面的版本发布实践

发布时间:2026/9/24 11:53:25

资讯中心
01
ARTICLE

CodeBurn 发布全流程指南:CLI、macOS 菜单栏与 Electron 桌面的版本发布实践

CodeBurn 发布全流程指南:CLI、macOS 菜单栏与 Electron 桌面的版本发布实践
【免费下载链接】codeburnFree, local tool to track AI coding token usage and cost across 37 tools and agents (Claude Code, Cursor, Codex, Gemini and more), by model, project, and task. npx codeburn项目地址https://gitcode.com/gh_mirrors/co/codeburn点击查看免费下载本指南面向 CodeBurn 仓库的维护者与贡献者完整讲解三种发布线的实际执行步骤CLInpm publish手动发布、macOS 菜单栏mac-v*标签触发 GitHub Actions 自动发布与 Electron 桌面应用desktop-v*标签 手动组装资产。读完本文你将掌握版本号管理、发布前自动化验收、签名公证、Homebrew 同步、资产替换与回滚等一整套可落地的发布操作。发布架构总览CodeBurn 是一个免费、本地化的 AI 编码用量与成本追踪工具支持 CLI、macOS 菜单栏、Electron 桌面、Windows 托盘等多样交付形态。不同形态的发布方式刻意不同其总体设计源自 RELEASING.md发布线触发方式自动化程度命名空间CLI维护者手动npm publish仅prepublishOnly钩子v*如v0.9.8macOS 菜单栏推送mac-v*标签.github/workflows/release-menubar.yml全自动mac-v*Electron 桌面手动构建 desktop-v*标签标签只触发只读的 Windows 安装器构建desktop-v*其中 CLI 与 macOS 菜单栏共享同一个版本号桌面应用版本号也跟随 CLI详见 app/DISTRIBUTION.md 的 Versioning 一节保证一个 CodeBurn 版本贯穿所有交付物。三种标签约定CLIgit tag v0.9.8macOS 菜单栏git tag mac-v0.9.8Electron 桌面git tag desktop-v0.9.8桌面标签命名刻意镜像菜单栏的mac-vversion约定把三类标签放在各自的命名空间里互不干扰见 app/DISTRIBUTION.md 的 Releases 一节。版本管理语义化版本 三端对齐CodeBurn 采用语义化版本major.minor.patch。CLI 与 macOS 菜单栏共享同一版本号以保证清晰度桌面应用的app/package.json的version同样跟随根目录package.json的 CLI 版本且需要在同一个变更里一起提升——启动画面、关于对话框与产物文件名都从该字段读取app/DISTRIBUTION.md 的 Versioning 一节。当前仓库根目录 package.json 中version为0.9.25这也与 CHANGELOG.md 顶部的0.9.25 - 2026-09-21记录一致。发布前验收自动化闸门与人工走查发布权威验收流程位于 docs/release-acceptance/README.md它是一个证据系统而非单元测试通过即可发布的口号。核心发布规则是只有当精确分发产物被 SHA 与校验和钉死、自动化闸门通过、两个 Persona 均完成、每个交付表面都有真实的点击走查证据、正确性独立对账、恢复用例通过、最终机器状态已知时候选版本才算就绪。运行自动化闸门每个发布候选都需要建立新的证据目录并用完全相同的候选版本运行自动化闸门node scripts/release-acceptance/run.mjs --mode package --output /absolute/path/to/evidence/run-id该运行器scripts/release-acceptance/run.mjs支持三种模式preflight仅采集候选版本与环境的 provenanceSHA、父提交、分支、版本、OS、架构、Node/npm/Swift 版本tests在 preflight 基础上追加根目录测试、锁测试与 Swift 原生测试package在 tests 基础上追加生产构建与菜单栏 App 打包运行器有几点硬性约束值得注意--output必须是绝对路径执行前工作区必须干净git status --porcelainv1有任何输出即失败执行后若工作区被改动则整体判fail——运行器绝不恢复被跟踪文件。它还会对打包出的CodeBurnMenubar-label.zip计算 SHA-256并把所有结果写入provenance.json、automated-results.json、timings.csv与logs/目录。验收用例注册表docs/release-acceptance/cases.csv 是完整的验收用例注册表覆盖 provenance、inventory、build、install、onboarding、clickthrough、performance、accuracy、recovery、residue、review 共 11 个阶段、60 条用例。每条用例都标注了methodscript脚本自动化、shell、computer-use、browser、mixed等automationfull/partial/manualevidence需要产出哪个证据文件如provenance.json、click-through.csv、timings.csvblocking是否发布阻塞项例如RA-BUILD-001根测试与锁测试script阻塞、RA-UI-001桌面端每个主目的地的点击走查computer-use手动阻塞、RA-PERF-004Web 首次有用绘制非阻塞等。跳过或不可达的表面应标记为blocked而不是pass。对于重大发布或涉及解析器/缓存/UI 的实质变更必须完成cases.csv中的每一行阻塞项把复核结果追加到 docs/release-acceptance/ledger/history.jsonl并要求在每个交付表面上完成已安装产物的真实点击走查。记录结构由 docs/release-acceptance/ledger.schema.json 定义包含run_id、candidate.sha、verdictready/conditional/not-ready/incomplete、surfaces逐表面状态、evidence五个必填证据路径等且历史账本只追加、不重写旧记录。自动化运行器不能替代 Desktop、Menu Bar 与浏览器的真实交互——验收阶梯从源码检查/单元测试逐级上升到冻结夹具 → 打包安装产物 → 真实交互 → 受影响机器证明。回归测试与构建每次发布前都应运行npm test npm run test:locks npm run buildnpm test覆盖tests/目录见 package.json 的 scripts 定义vitest run tests --exclude tests/cache-refresh-lock*npm run test:locks串行运行四个对并行敏感的cache-refresh-lock套件--poolOptions.forks.singleForktrueCI 将其视为仅报告性质因此需要发布者在这里人工检查npm run build会先执行tsup打包并拷贝生成dist/cli.js随后构建dash仪表盘确保构建无错误CLI 发布流程手动CLI 没有任何 GitHub Actions 工作流由维护者在干净工作区手动执行npm publish。完整步骤1. 更新版本号编辑根目录 package.json提升顶部version字段同时让 package-lock.json 同步npm 可自动处理npm version version例如npm version 0.9.8会同时更新两个文件并创建提交。也可以手改package.json后运行npm install重新生成 lockfile。2. 更新 Changelog编辑 CHANGELOG.md把 Unreleased 区块的所有变更移入带版本号与日期的新区块## Unreleased ### ... ## 0.9.8 - 2026-05-10 ### Added - Feature X ### Fixed - Bug Y提交这些变更git add CHANGELOG.md package.json package-lock.json git commit -m chore: bump to 0.9.83. 发布到 npmnpm publishpackage.json中的prepublishOnly脚本会先执行npm run build先打包 litellm 定价快照再运行tsup生成dist/cli.jsbin字段指向dist/cli.jsfiles字段只发布dist与THIRD_PARTY_NOTICES.md并排除dist/parse-worker.js.map。若在新机器上首次发布需先执行npm login。4. 打标签npm 接受发布后打标签并推送git tag v0.9.8 git push origin v0.9.8该标签用于人工引用并锚定 GitHub Release当前 CLI 的v*标签不会触发任何工作流。5. 验证 npm 发布npm view codeburn version5b. 同步 Homebrew Tapgetagentseal/homebrew-codeburntap 不会自动更新——每次 CLI 发布都必须手动提升否则会漂移issue #716 曾落后六个版本curl -sLO https://registry.npmjs.org/codeburn/-/codeburn-version.tgz shasum -a 256 codeburn-version.tgz # 编辑 tap 中的 Formula/codeburn.rb更新 url 版本号与 sha256提交并推送6. 创建 GitHub Release使用 GitHub CLI从 changelog 提取对应版本的说明gh release create v0.9.8 --title v0.9.8 --notes $(sed -n /^## 0.9.8/,/^## /p CHANGELOG.md | head -n -1)也可以在网页端起草 Release把 changelog 区块复制进正文。macOS 菜单栏发布流程自动macOS 菜单栏单独发布、拥有独立的 GitHub Release但与 CLI 共享同一版本号。1. 同样提升版本号沿用 CLI 的版本提升流程package.json与CHANGELOG.md都反映共享版本。2. 打 macOS 标签CLI 标签发布后为菜单栏创建独立标签git tag mac-v0.9.8 git push origin mac-v0.9.83. GitHub Actions 自动构建推送mac-v*标签会触发 .github/workflows/release-menubar.yml该工作流运行在macos-latest上依次执行检出仓库运行mac/Scripts/package-app.sh v0.9.8使用 Developer ID Application 证书对 App 签名交给 Apple 公证并钉上票据生成 zip 包CodeBurnMenubar-v0.9.8.zip计算 SHA-256 校验和CodeBurnMenubar-v0.9.8.zip.sha256将两者上传到名为 Menubar v0.9.8 的 GitHub Release构建机上的脚本输出大致为✓ Built /path/mac/.build/dist/CodeBurnMenubar-v0.9.8.zip ✓ Checksum /path/mac/.build/dist/CodeBurnMenubar-v0.9.8.zip.sha256 sha256-hash CodeBurnMenubar-v0.9.8.zip该工作流还支持workflow_dispatch手动触发可传version输入默认dev-preview手动运行时会上传 Actions artifact 而不创建 Release。注意package-app.sh的真实打包脚本位于 mac/Scripts/package-app.shRelease 实际是 x64/arm64 通用包。整个过程无需人工介入。4. 验证发布工作流完成后GitHub Release 页面会显示 zip 与 sha256 文件。已安装的 CLI 执行codeburn menubar --force会抓取最新的、同时包含两个资产的mac-v*菜单栏 Release校验校验和与 bundle 身份然后安装到~/Applications。菜单栏安装器逻辑位于 src/menubar-installer.ts其释放资产匹配模式、parseWindowsMsiVersion与暂存安装路径都要求_x64_en-US.msi命名桌面 Windows 侧细节详见 app/DISTRIBUTION.md。Homebrew Core 同步CodeBurn 已进入 homebrew-core。CLI 新版本发布到 npm 后homebrew-core 的 formula 由 Homebrew 的机器人自动更新也可手动提升brew bump-formula-pr codeburn --url https://registry.npmjs.org/codeburn/-/codeburn-VERSION.tgz用户通过brew install codeburn安装、brew upgrade codeburn升级。Electron 桌面发布流程手动组装桌面应用app/在desktop-vversion标签下手动发布。macOS 与 Linux 产物按 app/DISTRIBUTION.md 的说明手动构建推送标签会同时触发windows-latest上只读的Build Windows installer工作流。1. 构建桌面产物桌面应用由electron-builder构建三个平台均可从同一台 macOS 主机交叉构建无需 Windows/Linux 机器无需 winenpm --prefix app install npm --prefix app run package # macOSarm64 与 x64 npm --prefix app run package:win # Windows NSIS 安装器x64 npm --prefix app run package:linux # Linux AppImagex64 npm --prefix app run package:store # Microsoft Store AppXx64仅 Windows 主机Linux 目标与架构可通过直接调用 electron-builder 扩展cd app npx electron-builder --linux AppImage deb # x64 AppImage deb npx electron-builder --linux AppImage deb --arm64 npx electron-builder --linux rpm --x64 # 需要 brew install rpmrpmbuildpackage会先运行npm run stage-cli重建根 CLI 并暂存自包含 bundle 到app/build/cli见 scripts/stage-cli.mjs再编译electron/与构建 renderer最后执行electron-builder --macafterPack钩子scripts/after-pack.cjs把暂存 CLI 复制进Contents/Resources/cli使其落入代码签名内。桌面产物落在app/release/gitignored。关键产物清单以 macOS 为例CodeBurn-version-arm64.dmg、CodeBurn-version.dmgCodeBurn-version-arm64-mac.zip、CodeBurn-version-mac.zip对应的.blockmap文件差分更新元数据当前无自动更新器暂不使用2. 推送桌面标签git tag desktop-v0.9.8 git push origin desktop-v0.9.8推送desktop-vversion标签会在windows-latest上运行Build Windows installer工作流。该工作流要求标签版本、根 package 版本与应用 package 版本三者一致且构建必须在app/release/顶层恰好产出一个CodeBurn-Setup-version.exe与一个匹配的.exe.blockmap否则失败。它会以CodeBurn-Windows-InstallerActions artifact 上传这些文件。工作流具有只读仓库权限绝不自动发布 Release 资产artifact 保留 30 天。3. 组装并验证完整资产发布桌面 Release 前发布负责人必须下载该工作流 artifact手动把两个 Windows 文件连同以下资产一起上传4 个 macOS.dmg/.zip文件Linux 的CodeBurn-version.AppImage、codeburn-desktop_version_amd64.deb、codeburn-desktop-version.x86_64.rpmWindows 的CodeBurn-Setup-version.exe与.exe.blockmap公布前必须确认在线 Release 包含全部四种平台资产。网站的下载链接会在 URL 中钉住该标签因此缺少安装器的 Release 即便有其它 Windows 分发渠道也是坏的。Windows 安装器使用显式nsis.artifactNameCodeBurn-Setup-${version}.${ext}。发布 Release 会触发只读的在线资产验证作业。如果资产是在发布后上传的需要带release_tag输入手动重跑Build Windows installer工作流并要求该验证作业通过。验证失败或缺失是发布阻塞项。4. 桌面构建的签名与公证要点macOS 桌面产物.dmg/.zip与CodeBurnMenubar-version.zip使用 Developer ID Application 证书签名团队XRVP7P7F9M、开启 hardened runtime、经xcrun notarytool公证并 stapled。两个已知坑app/DISTRIBUTION.md 的 Two gotchas 一节electron-builder 拒绝Developer ID Application:前缀应传裸证书通用名Resham Joshi (XRVP7P7F9M)而不是codesign本身接受的全名electron-builder 公证的是.app而非.dmgdmg 需要额外一轮 codesign notarize staplecodesign --force --sign Resham Joshi (XRVP7P7F9M) CodeBurn-version-arm64.dmg xcrun notarytool submit CodeBurn-version-arm64.dmg --keychain-profile codeburn-notary --wait xcrun stapler staple CodeBurn-version-arm64.dmg提交到仓库的app/package.json的build.mac仍声明identity: -ad-hoc与hardenedRuntime: false作为本地/开发默认值签名发布构建通过 electron-builder CLI 覆盖传入真实身份而不是修改该文件npx electron-builder --mac \ -c.mac.identityResham Joshi (XRVP7P7F9M) \ -c.mac.hardenedRuntimetrue \ -c.mac.entitlementsbuild/entitlements.mac.plist \ -c.mac.entitlementsInheritbuild/entitlements.mac.plist \ -c.mac.gatekeeperAssesstrue5. 桌面构建的验证命令codesign -dv --verbose2 app/release/mac-arm64/CodeBurn.app codesign --verify --deep --strict app/release/mac-arm64/CodeBurn.app spctl --assess --type execute --verbose app/release/mac-arm64/CodeBurn.app本地 ad-hoc 构建显示Signatureadhoc签名发布构建显示AuthorityDeveloper ID Application: Resham Joshi (XRVP7P7F9M)spctl报告sourceNotarized Developer ID。深度验证命令应退出 0。还可直接启动打包后的二进制做冒烟测试确认进程树稳定、主进程无did-fail-load错误app/DISTRIBUTION.md 的 Verifying a build 一节。替换已发布 Release 上的资产若发布带着损坏资产例如有构建错误的菜单栏 zip可在不创建新标签的情况下重新构建并上传修复资产。使用gh release upload的--clobber覆盖已有文件# 重新运行 mac/Scripts/package-app.sh v0.9.8 重新生成 zip 与 sha256 后 gh release upload mac-v0.9.8 mac/.build/dist/CodeBurnMenubar-v0.9.8.zip --clobber gh release upload mac-v0.9.8 mac/.build/dist/CodeBurnMenubar-v0.9.8.zip.sha256 --clobber菜单栏安装器会挑选最新的、同时包含CodeBurnMenubar-v*.zip与其校验和的mac-v*Release因此替换后用户执行codeburn menubar --force即可自动获得修复版本。桌面侧同理若资产在发布后上传需重跑Build Windows installer并带上release_tag输入且要求验证作业通过。回滚策略若已发布版本存在严重缺陷最快的路径是修复缺陷并发布新的补丁版本如 0.9.8 → 0.9.9。若标签尚未广泛分发可删除损坏标签git tag -d v0.9.8 git push origin --delete v0.9.8注意npm 不允许向同一版本重复发布。若必须从 npm 撤销使用npm unpublish codeburn0.9.8 --force需要 Owner 角色但这不推荐且所有已安装该版本的用户仍保留它菜单栏回滚直接打新标签mac-v0.9.9让工作流构建上传。用户会在菜单栏设置中看到更新提示并自动升级或手动执行codeburn menubar --force总结CodeBurn 的三条发布线各有分工CLI 发布是手动的提升版本 → 更新CHANGELOG.md→ 提交 →npm publish→ 打标签并创建 GitHub Release → 同步 Homebrew tap 与 homebrew-coremacOS 菜单栏发布是自动的推送mac-v*标签触发 .github/workflows/release-menubar.yml自动完成构建、签名、公证、打包 zip、生成校验和与发布Electron 桌面发布手动组装在desktop-v*标签下由只读的windows-latest工作流产出权威的 Windows NSIS 安装器发布者手动汇总四平台资产所有发布前都必须通过 docs/release-acceptance/README.md 定义的证据化验收闸门并以 docs/release-acceptance/cases.csv 注册表为准逐项核验赞分享【免费下载链接】codeburnFree, local tool to track AI coding token usage and cost across 37 tools and agents (Claude Code, Cursor, Codex, Gemini and more), by model, project, and task. npx codeburn项目地址https://gitcode.com/gh_mirrors/co/codeburn点击查看免费下载相关推荐Angular CLI 发布流程全解析Caretaker 值班、版本发布与新 NPM 包发布实战指南Angular CLI 发布流程全解析Caretaker 值班、版本发布与新 NPM 包发布实战指南 导读 本文基于 Angular CLI 官方仓库的 发布CLI开发工具前端构建构建工具代码生成前端Sim 桌面应用 Electron 大版本升级清单从 Fuse 策略到分阶段发布的全流程实战指南Sim 桌面应用 Electron 大版本升级清单从 Fuse 策略到分阶段发布的全流程实战指南 Electron 每次大版本升级都伴随着 Chromium人工智能AI AgentAgent 工作流工作流自动化AI 应用后端前端桌面应用CLIStencil 版本发布全流程指南自动化 CI 发布、手动发布与发布后跟进实践Stencil 版本发布全流程指南自动化 CI 发布、手动发布与发布后跟进实践 Stencil stencil/core 是一套构建可扩展、企业级 We开发工具前端前端构建创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
02
RELATED NEWS

相关资讯

更多网站建设与数字化升级内容

03
WHY YAOTU

想打造同款高转化官网?

懂行业、懂生意,从建站到增长一站式陪跑

场景化定制

不做模板站,围绕你的业务场景量身设计,小众不撞款。

营销型架构

以转化目标组织内容与路径,让官网真正带来询盘。

全周期服务

设计、开发、运营、运维一体,上线只是开始。

免费获取你的建站方案

留下需求,专属顾问 24 小时内为你输出方案建议。