Rancher Desktop Linux 发布流程：从 OBS 包管理到 AppImage/RPM/DEB 构建指南

• 桌面应用
• 云原生
• 容器编排

本文深入解析 Rancher Desktop 在 Linux 平台上的发布流程：以 Open Build Service（OBS）为核心，如何区分dev与stable两条发布通道、何时需要修改 OBS、如何用osc copypac创建新版本包，以及从 GitHub Actions 触发到最终通过zypper install、apt install交付给用户的完整链路。读完本文，你将掌握 Rancher Desktop 每个 Linux 版本从代码推送、S3 中转、OBS 服务触发到多格式打包的全过程，并能够独立执行新 major/minor 版本的 OBS 更新操作。

前置知识：先读 OBS 使用指南

OBS（Open Build Service）是 Rancher Desktop 在 Linux 上构建与分发 rpm、deb、AppImage 等格式的载体。在动手修改任何 OBS 配置之前，请先阅读 OBS Tips Documentation，其中包含与 OBS 协作时必须熟悉的重要信息，例如：

• 项目（Project）：OBS 中一切操作的容器，仓库、包、服务都必须归属某个项目。项目可以嵌套子项目，Rancher Desktop 的项目isv:Rancher是isv根项目下的子项目，项目名用冒号拼接各层父项目名；
• 仓库（Repository）：配置在项目上，可理解为包管理器视角的远程下载端点，同一项目可配置多个仓库以从同一份源码产出多种格式的包；
• 包（Package）：OBS 中的包是一组参与构建的文件集合（源码与 rpm.spec等元数据），从用户包管理器角度看，一个 OBS 包恰好对应一个版本；
• 服务（Service）：可以以多种方式触发的脚本，常见用途是在打包前从版本控制获取最新代码。

obs.md还给出了实用的本地构建技巧：osc build --download-api-only可绕过缓慢的镜像下载依赖缓存；osc build --no-service可跳过构建前的服务执行；构建完成后可从终端输出末尾找到构建产物路径。

何时需要修改 OBS

OBS 的配置设计原则是：只有在发布新的 major 或 minor 版本时才需要动手修改 OBS。例如发布 1.11.0 时需要做出变更；而发布 1.11.1 这类 patch 版本时，除了常规检查外什么都不用做。

原因在于 OBS 包的粒度：从用户包管理器的角度看，一个 OBS 包代表且仅代表一个版本，因此每个 major-minor 版本（如 1.11、1.12）都需要一个独立的 OBS 包；而同一 major-minor 下的 patch 版本（1.11.1、1.11.2）会复用同一个 OBS 包，OBS 服务每次被触发时都会拉取最新的构建产物，无需新建包。

发布新 major/minor 版本时如何修改 OBS

准备osc

开始前必须先完成osc命令行工具的安装与配置（openSUSE 环境下可通过zypper install osc安装）。OBS 虽然有 Web 界面，但根据obs.md的建议，应使用它来查看包状态或做小改动，其余操作应尽量使用功能更完整的osc。

用osc copypac复制现有包

复制命令的签名如下：

osc copypac <source_project> <source_package> <destination_project> <destination_package>

例如，将isv:Rancher:dev项目中的rancher-desktop-release-1.11包复制为同项目下的rancher-desktop-release-1.12：

osc copypac isv:Rancher:dev rancher-desktop-release-1.11 isv:Rancher:dev rancher-desktop-release-1.12

之所以可以直接复制，是因为新 major-minor 版本的包结构与上一个版本几乎完全一致，只需在复制结果上做版本号替换即可。

更新_service文件与 Meta 信息

复制完成后，必须更新包内的_service文件和包的Meta页签，使其指向新的 major-minor 版本。最便捷的方式是通过 OBS Web 界面（需要登录）操作：以 1.11 → 1.12 为例，一般只需把包内所有1.11替换为1.12。

不过官方文档强调：最好理解你正在改动的内容，而不是盲目全局替换。_service文件决定了 OBS 从哪个 S3 对象下载 zip、从仓库拉取哪些与包格式相关的文件；Meta 页签则包含包所属项目、仓库与构建目标等元信息。替换完成后，服务会自动运行，构建随即开始。

检查构建结果

构建完成后务必检查结果——构建过程可能因为虚拟机不可用、依赖解析失败等原因中断。常见处理方式：

• 在 Web 界面左侧导航栏点击"Trigger Services"重新触发服务；
• 或从包主页点击某个包格式（如 AppImage），再点击"Trigger rebuild"单独触发该格式的重建；
• 这两项操作均需登录 Web 界面。

此外，还应当验证用于下载"latest"AppImage 的链接是否真的下载到了最新 AppImage——该链接有时不会及时更新。

Linux 发布如何实际运转：两条通道

Rancher Desktop 的 Linux 发布分为dev与stable两条通道，分别对应 OBS 的isv:Rancher:dev与isv:Rancher:stable项目，二者构建流程相似但触发方式不同。

dev通道：面向开发者的持续构建

dev通道面向开发者及少数勇于尝鲜的用户，对应 isv:Rancher:dev OBS 项目。流程如下：

1. 新提交被推送到main或release-X.Y（如release-1.2、release-1.11）格式的分支，触发package.ymlGitHub Actions 工作流。该工作流构建 Rancher Desktop，并将产物以rancher-desktop-linux-<branch_name>.zip的形式上传到 S3 桶；
2. package.yml作为最后一步，触发与触发工作流的分支所对应的 OBS 包执行服务运行。服务会从 S3 下载并解包该 zip，同时从 rancher-desktop 仓库拉取与将要构建的包格式相关的文件；
3. 新文件触发 OBS 构建；
4. OBS 构建完成后，用户即可通过zypper install、apt install等方式下载到新版本包。

仓库中的 .github/workflows/package.yaml 印证了上述链路。在packagejob 的 Linux 平台步骤中：

• 先执行yarn build与yarn package完成构建打包；
• 再通过aws s3 cp将dist/rancher-desktop-*-linux.zip上传到s3://rancher-desktop-assets-for-obs，文件名按分支名动态生成（PR 场景下会把GITHUB_REF_NAME中的/替换为-，因为斜杠不能出现在文件名中）；
• 最后通过curl -X POST携带OBS_WEBHOOK_TOKEN调用https://build.opensuse.org/trigger/runservice?project=isv:Rancher:dev&package=rancher-desktop-${GITHUB_REF_NAME}触发对应 OBS 包的服务运行；
• 若AWS_ACCESS_KEY_ID或OBS_WEBHOOK_TOKEN未配置（如 fork 仓库的 PR 场景），工作流会打印 "Secrets unavailable, skipping." 并跳过 OBS 触发步骤。

工作流的触发条件同样印证了文档描述：push事件限定在main与release-*分支、以及所有 tag 上，且 OBS 触发步骤带有github.ref_type == 'branch'与分支名前缀检查，确保只有分支推送而非 tag 推送会走 dev 通道。

stable通道：正式发布承载地

stable通道承载真正的发布版本，面向实际用户，对应 isv:Rancher:stable OBS 项目。构建过程与dev通道相似，但触发方式不同：OBS 构建由已发布的 GitHub release 触发，而不是由特定格式分支上的新提交触发。流程如下：

1. 新 release 发布，触发linux-release.ymlGitHub Actions 工作流。该工作流从 release 拉取 Linux zip 文件，并以rancher-desktop-linux-X.Y.zip（如rancher-desktop-linux-1.12.zip）的命名上传到 AWS S3；
2. linux-release.yml触发与已发布 release 的 tag 所对应 major/minor 版本的 OBS 包执行服务运行。服务从 S3 下载并解包 zip，同时从 rancher-desktop 仓库拉取与包格式相关的文件；
3. 新文件触发 OBS 构建；
4. OBS 构建完成后，用户即可通过zypper install、apt install等方式下载到新版本包。

仓库中的 .github/workflows/linux-release.yaml 提供了这套流程的实现细节：

• 工作流在release事件的published类型上触发（也支持workflow_dispatch手动触发）；
• 先从 tag（形如v1.12.0）中解析出版本号：release_zip_name="rancher-desktop-linux-${version_with_v}.zip"保留完整带v的版本，再通过sed正则s/v([0-9]+\.[0-9]+)\.[0-9]+.*/\1/g提取出major_minor（如1.12）作为 S3 对象名rancher-desktop-linux-${major_minor}.zip；
• 用curl -L从 GitHub release 下载 zip 到dist/，再aws s3 cp上传到s3://rancher-desktop-assets-for-obs；
• 最后用curl -X POST携带OBS_WEBHOOK_TOKEN调用https://build.opensuse.org/trigger/runservice?project=isv:Rancher:stable&package=rancher-desktop-${MAJOR_MINOR}触发稳定通道对应包的构建。

注意到稳定通道上传的 S3 对象名只含major_minor（不带 patch 号），这意味着同一 major-minor 下的多个 patch release 会覆盖同一个 S3 对象并复用同一个 OBS 包——这正是文档开篇"patch 版本无需修改 OBS"结论的直接体现。

深度解读：OBS 从 zip 构建出哪些 Linux 包格式

OBS 服务拉取的"与包格式相关的文件"最终指向 packaging/linux 目录中的构建描述。Rancher Desktop 的 Linux 产物由 packaging/electron-builder.yml 的linux段定义：target: [ zip ]且artifactName: ${name}-${version}-linux.zip，即 GitHub Actions 侧只产出 zip；zip 上传到 S3 后，由 OBS 侧的服务负责解包并依据下述描述文件加工出面向用户的多种格式。

• AppImage：由 packaging/linux/appimage.yml 驱动。构建脚本先unzip $BUILD_SOURCE_DIR/rancher-desktop.zip解包，将chrome-sandbox权限设为04755（Electron 沙箱所需的 setuid 位），生成桌面文件与图标，并把 lima 自带的 qemu 二进制与库文件移动到系统路径后建立符号链接。文档中"点击 AppImage 触发重建"以及"检查 latest AppImage 链接"的建议，正是针对这种格式；
• rpm / deb：由 packaging/linux/rancher-desktop.spec 统一驱动。%if "%{_vendor}" == "debbuild"分支为 deb 构建设置Packager: SUSE与 Debian 命名空间的运行时依赖（qemu-utils、pass、gnutls-bin等）；非 deb 分支按 fedora/rhel 与 openSUSE 分别声明Requires。%build阶段用 ImageMagick 的convert从logo-square-512.png生成 hicolor 多尺寸图标，并把 lima tarball 中自带的 qemu 二进制、库与 share 目录删除（这些将由发行版自带 qemu 提供），%files段中%attr(4755,root,root)同样为chrome-sandbox设置了 setuid 权限；
• flatpak：packaging/linux/flatpak.yaml 文件头部明确标注"This file is unused and just kept for reference for plain flatpak builds"，即该文件仅作参考、当前不参与实际发布链路，其finish-args中--device=kvm、--socket=x11/wayland等权限声明可供了解 flatpak 形态下的沙箱需求。

从源码结构还可以印证：OBS 构建产物（尤其是 AppImage）是 Linux 端自动更新的基础。pkg/rancher-desktop/main/update/index.ts 在检测到 Linux 平台时实例化 electron-updater 的AppImageUpdater；pkg/rancher-desktop/main/update/LonghornProvider.ts 在选择更新资产时按asset.name.endsWith('AppImage')筛选。而 pkg/rancher-desktop/integrations/unixIntegrationManager.ts 中提到rdctl需要找到 AppImage 的路径，说明 AppImage 形态下程序内路径解析与常规安装形态不同。因此，保证 OBS 产出的最新 AppImage 可下载、可更新，是整个发布链路的最后一环。

与整体发布流程的衔接

Linux 发布只是 Rancher Desktop 全平台发布的一部分。若要发布一个完整版本，可结合 Release Checklist 中的步骤：更新 package.json 版本号、为 release 分支打 tag 并等待 CI 构建产物、签署 Windows 与 macOS 安装包、更新 release notes 与升级响应器配置等。Linux 侧的关键交付物（rpm/deb/AppImage）正是由本文所述的 OBS 通道在 release 发布后自动产出，发布者无需手动上传 Linux 安装包，只需按文档建议检查构建结果与 latest 链接即可。

小结

• 何时动手：只有发布新的 major/minor 版本才需要修改 OBS；patch 版本仅需常规检查；
• 如何动手：osc copypac复制上一个版本包 → 在 Web 界面更新_service与 Meta 中的版本号 → 检查构建结果，必要时用 "Trigger Services" 或 "Trigger rebuild" 重建；
• 两条通道：dev（isv:Rancher:dev）由main/release-X.Y分支推送触发，stable（isv:Rancher:stable）由已发布的 GitHub release 触发，二者最终都汇聚到 S3 中转、OBS 服务解包、OBS 构建、包管理器分发的同一模式；
• 落地依据：package.yaml 与 linux-release.yaml 是两条通道的自动化实现，appimage.yml 与 rancher-desktop.spec 定义了从 zip 到用户可安装包的具体加工方式。

• 桌面应用
• 云原生
• 容器编排