bottom 的部署流程全解析：Nightly 与 Stable 双轨发布、crates.io / Chocolatey / winget 手动分发实操

bottom 的部署流程全解析：Nightly 与 Stable 双轨发布、crates.io / Chocolatey / winget 手动分发实操

【免费下载链接】bottomYet another cross-platform graphical process/system monitor.项目地址: https://gitcode.com/GitHub_Trending/bo/bottom

本文面向希望参与 bottom（一款用 Rust 编写的跨平台终端图形化进程/系统监控工具）构建、打包与分发的开发者。文章以仓库文档 deploy_process.md 为主体，系统梳理 bottom 的两条发布主链路（Nightly 每日自动构建与 Stable 标签触发发布）、手动分发的三个渠道（crates.io、Chocolatey、winget），并结合仓库内的 Cargo.toml、wix/main.wxs、Cross.toml 与 Chocolatey 打包脚本等源码佐证，帮助读者从“能跑起来”进阶到“能发布一个 release”。

部署流程概览：两条发布主线与三个手动渠道

bottom 的部署（deploy）体系围绕Nightly与Stable两条主线展开，两者都依赖 GitHub Actions 完成“构建产物 → 上传发布”的自动化，区别在于触发方式与发布目的：

发布线	触发方式	产出物	目的
Nightly	每日 00:00 UTC 自动触发（也可手动触发）	二进制与安装包，上传至 nightly release	持续验证各目标平台能否构建成功
Stable	手动触发，或创建形如x.y.z的合法 tag 自动触发	二进制与安装包，上传至新的 GitHub release（草稿）	正式版本发布

需要特别说明的是，这两个 workflow 并不会自动完成所有分发渠道。以下部署必须由维护者手动处理：

• Chocolatey（Windows 包管理器）发布；
• crates.io（Rust 生态的 crate 仓库）发布。

此外，winget（Windows 另一个包管理器）通常由社区热心人士代为发布，但也可以手动触发，手动触发时需要重新生成一些 secrets（见下文 winget 小节）。

从仓库结构看，本仓库虽然没有直接包含.github/workflows目录，但相关证据充分：文档明确引用了nightly.yml与deployment.yml两个 workflow；build_process.md 进一步说明，核心构建逻辑统一放在build_releases.yml中，由 Nightly/Stable 两个 wrapper workflow 调用；构建出的产物主要包括多平台二进制、Windows 的 MSI 安装包、Debian 系发行版的.deb包。另外，本文所讨论的部署流程与 packaging-and-distribution.md 描述的“二进制发布 + 手动构建”互为补充——前者讲自动化发布，后者讲手工打包。

注意：部署文档中标记为 WIP（Work in Progress），且明确声明本节面向希望构建/发布 bottom 的人，而非普通用户。普通用户安装请直接使用 README 中列出的安装方式。

Nightly：每日自动构建与 mock 测试模式

Nightly 构建是 bottom 部署体系里“几乎全自动”的一环：

• 自动触发：每天 00:00 UTC 由 GitHub Action（nightly.yml）执行，从main分支构建二进制/安装包，并上传到 nightly release。
• 持续验证价值：它本质上也是一种“构建冒烟测试”——验证在我们要支持的所有目标平台上，二进制是否都能成功构建，构建工作流是否有改动导致的回归。
• 手动触发：可以在任意分支上手动运行该 workflow，并通过参数区分两种运行模式：
  • 参数设为mock：只跑构建流程、不真正更新 nightly release，用于测试构建工作流本身的改动；
  • 参数设为其他任意值：触发一次真实的（non-mock）nightly 发布。

这一设计与仓库的 schema 发布节奏吻合：schema/nightly/bottom.json即为 nightly 配置 schema，由 scripts/schema/nightly.sh 通过cargo run --manifest-path scripts/schema_gen/Cargo.toml生成，每晚随 nightly 一起刷新，保证 nightly 文档站点始终能展示“最新”配置格式。

构建产物与关键环境变量

结合 build_process.md，Nightly/Stable 共用的build_releases.yml对二进制构建采取以下步骤：

1. 为 runner 配置 Rust 工具链；
2. 启用构建缓存（cache）；
3. 执行 release 构建，关键参数如下：
   • --features deploy：只启用发布构建需要的 crates 特性。查看 Cargo.toml 可确认deploy = ["battery", "nvidia", "zfs"]，即发布构建会带上电池、NVIDIA GPU 与 ZFS 支持；而logging、generate_schema等仅用于开发/文档生成的特性不会进入发布构建；
   • --locked：锁定依赖版本，确保可复现构建；
   • 设置BTM_GENERATE: true、COMPLETION_DIR: "target/tmp/bottom/completion/"、MANPAGE_DIR: "target/tmp/bottom/manpage/"，用于生成 manpage 与 shell 补全文件（生成逻辑与产物位置详见 packaging-and-distribution.md 的 “Manpage and completion generation” 一节）。
4. 将二进制与 manpage/completions 打包捆绑；
5. 清理临时产物。

部分目标平台使用cross做交叉编译。仓库根目录的 Cross.toml 给出了实例：它允许构建环境透传RUST_BACKTRACE、BTM_GENERATE环境变量，并为x86_64-unknown-netbsd目标定义了pre-build步骤——在容器内安装 curl/xz-utils、下载 NetBSD 9.3 的 base/comp 集合中的libkvm等库，为交叉编译准备 sysroot。这说明 bottom 的发布矩阵覆盖了包括 NetBSD 在内的多个非主流平台。

Stable：tag 触发、草稿发布与人工收尾

Stable 发布由deployment.yml驱动，常规使用方式是打一个x.y.z形式的 tag：

git tag 0.6.9 && git push origin 0.6.9

推送 tag 后，deployment workflow 会自动触发，执行与 Nightly 相同的构建流程，并把产物上传到一个新的 draft（草稿）release上。此时还需要维护者：

1. 填写 release 的详细说明（changelog 等）；
2. 确认无误后手动点击发布（publish）。

也就是说，tag 只负责“构建 + 上传草稿”，最终发布动作仍由人确认，防止未完善的版本被意外公开。

此外，Stable 发布也支持在界面上手动触发（同样需要先确保代码与依赖状态无误）。与 Nightly 一样，Stable 发布同样不会自动处理 crates.io 与 Chocolatey，这两者必须走下文的手动流程。

手动分发渠道之一：crates.io（cargo publish）

bottom 以 crate 形式发布到 crates.io（包名bottom，见 Cargo.toml）。crates.io 的部署完全手动，流程如下：

1. 发布前验证：确认一切都能正常构建和运行（这一步理应在 release 之前就完成）。从 Cargo.toml 可以看到 crate 的exclude列表排除了 docs、scripts、wix、assets 等目录，只发布源码本身，因此验证时也应注意本地构建与 crates.io 上发布的源码构建保持一致。
2. 执行发布：

cargo publish

cargo publish会校验包元数据、打包并上传到 crates.io。由于本仓库 crate 版本为 0.14.8（见 Cargo.toml），发布前请确保Cargo.toml中的version已递增，并同步打好同版本 tag，保持 GitHub release 与 crates.io 版本一致。

提示：Rust 版本要求请关注 Cargo.toml 中的rust-version = "1.95.0"字段（注释明确说明这不是官方 MSRV，只是作者测试过可构建的最低版本）——crates.io 会依据该字段约束使用者的工具链版本。

手动分发渠道之二：Chocolatey

Chocolatey 是 Windows 生态的包管理器，bottom 的 Chocolatey 发布链路包含“自动准备”与“手动部署”两个阶段：

1. 自动准备 PR：在 GitHub release 发布后，仓库 choco-bottom 会自动收到一个包含正确部署文件的新 PR（该仓库专门维护 bottom 的 Chocolatey 打包）。
2. 人工审核：维护者需要检查这个 PR 是否正确，正确则合并。
3. 本地拉取并部署：合并后 pull 到本地，按照 choco-bottom 仓库 README 的指引执行部署。
4. 部署前必须实测：文档明确强调——在部署前至少完整测试一次安装与运行。
5. 等待校验：如果一切正确，Chocolatey 上会出现新构建，需要一定时间完成验证。

仓库为这套流程提供了打包基础设施：scripts/windows/choco/ 目录下包含：

• bottom.nuspec.template：Chocolatey 包的 nuspec 模板，定义了包 ID（bottom）、版本占位符$version、依赖说明（当前依赖 Visual C++ Redistributable for Visual Studio 2015 的 vcredist2015 包）、requireLicenseAcceptance以及tools\**的文件打包范围；
• chocolateyinstall.ps1.template：安装脚本模板，使用Install-ChocolateyZipPackage从 GitHub release 下载bottom_x86_64-pc-windows-msvc.zip，并注入版本号与 sha1 校验和占位符；
• choco_packager.py：将上述两个模板与真实产物结合——读取 64 位部署文件计算 sha1 哈希，通过Template.safe_substitute把$version、$hash_64填入模板，生成最终的 nuspec 与 chocolateyinstall.ps1 文件。

这套脚本与 choco-bottom 仓库的自动 PR 机制相呼应：一旦新的 GitHub release 产生，即可用生成好的文件提交 PR，保持包版本与上游同步。

手动分发渠道之三：winget

winget（Windows Package Manager）的分发通常由社区热心人士代为完成，但也可以手动触发，方式是通过专门的 winget-bottom 仓库。

需要特别注意的是：手动触发 winget 发布要求重新生成一些 secrets。这是因为 winget 仓库的提交需要认证凭据，而凭据可能存在有效期或需要按发布流程轮换。文档只提示了这一点，未给出具体 secrets 清单——实际操作时应以 winget-bottom 仓库的 README 与 GitHub Actions secrets 配置为准。

发布矩阵的源码佐证：MSI、deb 与桌面集成

尽管部署文档聚焦于“流程”，仓库内仍有大量文件直接服务于发布产物的生成，可作为理解部署细节的补充证据：

• Windows MSI 安装包：wix/main.wxs 是cargo-wix使用的 WiX 模板（Cargo.toml 中的[package.metadata.wix]指定输出bottom_installer.msi与产品图标 assets/icons/bottom.ico）。该模板会：
  • 依据$(sys.BUILDARCH)自动选择ProgramFiles64Folder或ProgramFilesFolder作为安装目录；
  • 把btm.exe安装到bin目录，并可选地将其加入系统 PATH（对应 Feature 节点Environment）；
  • 将构建期生成的五份 shell 补全（Powershell_btm.ps1、Nushellbtm.nu、Fishbtm.fish、Bashbtm.bash、Zsh_btm）一并安装到completions目录——这正是 build_process.md 中BTM_GENERATE生成物在安装包内的落点；
  • 包含 License 侧车文件 wix/License.rtf 与升级保护逻辑（MajorUpgrade+DowngradeErrorMessage）。
• Debian.deb包：Cargo.toml 的[package.metadata.deb]定义了 deb 打包清单：btm二进制安装到/usr/bin/、manpage 到/usr/share/man/man1/、bash/fish/zsh 补全到对应目录、desktop/bottom.desktop 到/usr/share/applications/、assets/icons/bottom-system-monitor.svg 到 hicolor 图标目录；针对arm64（armhf）变体还分别声明了libc6的依赖约束。同时 build_process.md 提到 ARM 架构的 deb 通过 Docker 容器（cargo-deb-arm）构建，x86 则原生使用cargo-deb，并用dpkg校验架构正确性。
• RPM 打包：Cargo.toml 还预留了[package.metadata.generate-rpm]资产清单，资产结构与 deb 一致，供 RPM 系发行版（Fedora/RHEL/openSUSE 等）打包参考。

发布前自检清单

综合部署文档与仓库配置，一次完整的 Stable 发布大致应依次完成以下动作：

1. 代码与测试就绪：本地cargo build --release --locked构建通过，测试与 clippy/rustfmt 检查通过（CI 检查项可参考 issues-and-pull-requests.md 中的 PR 流程说明）；
2. 确认版本号：Cargo.toml的version、CHANGELOG、README 中的版本信息一致；
3. 打 tag 并推送：git tag x.y.z && git push origin x.y.z，触发 Stable workflow 生成草稿 release；
4. 完善并发布草稿：填写 release notes 后点击发布；
5. 手动发布 crates.io：确认无误后执行cargo publish；
6. 处理 Chocolatey：合并 choco-bottom 的自动 PR，本地按 README 部署，部署前至少实测一次安装与运行；
7. 处理 winget（如无社区代劳）：通过 winget-bottom 手动触发，注意重新生成所需 secrets。

Nightly 链路则更简单：日常由定时任务自动完成；若要验证工作流改动，可在目标分支上以mock参数手动运行，确认各平台构建全部通过后再以非 mock 参数触发真实发布。

结语

bottom 的部署体系体现了“自动化为主、关键动作人工把关”的典型开源发布实践：Nightly 与 Stable 共用一套build_releases.yml构建矩阵（多平台二进制 + MSI + deb），通过 tag 或定时任务触发，最终发布动作（release 详情、crates.io、Chocolatey、winget）仍保留人工环节。对于想为 bottom 贡献打包工作或自行 fork 维护发布流程的开发者，建议以本文为入口，进一步阅读 build_process.md 了解构建细节、packaging-and-distribution.md 了解手动打包与补全生成，并对照 Cargo.toml 中的 metadata 与 wix/main.wxs、scripts/windows/choco/ 下的模板，即可复现完整的发布链路。

【免费下载链接】bottomYet another cross-platform graphical process/system monitor.项目地址: https://gitcode.com/GitHub_Trending/bo/bottom