Finder-launched terminals now inherit a login PATH so tools like ollama resolve, destructive SFTP/editor actions require confirmation, and terminal search plus window dragging work again. SSH forwards and RDP sessions keep listeners and survive reconnect without FastPath crashes. Co-authored-by: Cursor <cursoragent@cursor.com>
133 lines
4.6 KiB
Markdown
133 lines
4.6 KiB
Markdown
# 发布指南
|
||
|
||
## 构建命令
|
||
|
||
```bash
|
||
# 推荐:当前平台完整门禁、打包、验证和 SHA-256
|
||
./scripts/build.sh
|
||
|
||
# macOS Apple Silicon 指定版本
|
||
./scripts/build.sh v2.1.1 mac-arm64
|
||
|
||
# Windows x86_64(推荐在 Windows CMD/PowerShell 中执行)
|
||
scripts\build.bat v2.1.1 win-x64
|
||
|
||
# 本地重复构建时缩短门禁;正式发布不要跳过
|
||
./scripts/build.sh v2.1.1 mac-arm64 --quick
|
||
```
|
||
|
||
`scripts/build.sh` 与 `scripts/build.bat` 面向 v2.1.x,会检查 Node、npm、Rust target 和五处版本元数据。显式传入不同于当前源码的新版本时,脚本会同步版本文件;它们只负责构建,不会自动创建 tag 或推送远程仓库。安装包和 `SHA256SUMS.txt` 输出到:
|
||
|
||
```text
|
||
release/v2.1.1/macos-arm64/
|
||
release/v2.1.1/windows-x64/
|
||
```
|
||
|
||
平台安装包必须在目标系统构建和验证。macOS 不能替代 Windows x86_64 实机打包。
|
||
|
||
### Windows 构建环境
|
||
|
||
建议使用 Windows 10/11 x64,并安装:
|
||
|
||
- Node.js 18+ 与 npm
|
||
- Rust stable 的 `x86_64-pc-windows-msvc` toolchain
|
||
- Visual Studio 2022 Build Tools,勾选 **Desktop development with C++**
|
||
- Windows 10/11 SDK
|
||
- Microsoft Edge WebView2 Runtime
|
||
|
||
首次准备:
|
||
|
||
```bat
|
||
rustup default stable-x86_64-pc-windows-msvc
|
||
rustup target add x86_64-pc-windows-msvc
|
||
npm ci
|
||
scripts\build.bat v2.1.1 win-x64
|
||
```
|
||
|
||
默认执行完整门禁;`--quick` 适合开发期重复构建,正式发布不要使用 `--skip-checks`。输出位于 `release\v2.1.1\windows-x64\`。没有代码签名证书时可以生成开发安装包,但 Windows SmartScreen 可能提示未知发布者。
|
||
|
||
## Gitee Release
|
||
|
||
构建、提交并推送对应 tag 后执行:
|
||
|
||
```bash
|
||
# 只检查附件,不访问 Gitee API
|
||
./scripts/release.py v2.1.1 --dry-run
|
||
|
||
# 创建或更新 Release,上传安装包和 SHA256SUMS.txt,并核验远程附件
|
||
./scripts/release.py v2.1.1
|
||
```
|
||
|
||
发布凭据从 `GITEE_TOKEN` 或 `~/.netrc` 的 `gitee.com` 条目读取,脚本不会输出 Token。脚本只读取 `release/v<版本>/` 下的 `.dmg`、`.exe`、`.msi` 和 `SHA256SUMS.txt`,上传成功后保留本地文件。远程已有同名同大小附件时会跳过;同名但大小不同时停止,避免静默覆盖已发布二进制。
|
||
|
||
macOS App 位于:
|
||
|
||
```text
|
||
src-tauri/target/release/bundle/macos/OpsXShell.app
|
||
```
|
||
|
||
指定 `aarch64-apple-darwin` target 时,产物位于对应 target 的 `release/bundle` 下。
|
||
|
||
## 临时 DMG
|
||
|
||
Tauri 调用 `hdiutil` 制作 DMG 时,可能在异常中断后留下:
|
||
|
||
```text
|
||
rw.<进程号>.OpsXShell_<版本>_aarch64.dmg
|
||
```
|
||
|
||
这些 `rw.*.dmg` 是可写临时镜像,不是发布包。确认没有正在运行的 Tauri/hdiutil 打包任务后可以删除。正式包没有 `rw.<数字>.` 前缀。
|
||
|
||
如果 DMG 脚本报错 `resource busy`,先检查是否正从临时挂载目录运行 OpsXShell:
|
||
|
||
```bash
|
||
hdiutil info
|
||
lsof +D /Volumes/<临时卷名>
|
||
```
|
||
|
||
先正常退出该 OpsXShell 进程,再卸载对应的临时卷并重新构建。不要在应用仍从卷内运行时直接删除 `rw.*.dmg`。
|
||
|
||
## 签名和公证
|
||
|
||
标签 `tauri-v*` 会触发 `.github/workflows/tauri-release.yml`。正式标签构建要求签名变量齐全。
|
||
|
||
macOS:
|
||
|
||
- `APPLE_CERTIFICATE`
|
||
- `APPLE_CERTIFICATE_PASSWORD`
|
||
- `APPLE_SIGNING_IDENTITY`
|
||
- `APPLE_ID`
|
||
- `APPLE_PASSWORD`
|
||
- `APPLE_TEAM_ID`
|
||
|
||
Windows:
|
||
|
||
- `WINDOWS_CERTIFICATE_BASE64`
|
||
- `WINDOWS_CERTIFICATE_PASSWORD`
|
||
|
||
缺少凭据时只能生成开发构建,不能标记为正式签名或已公证版本。
|
||
|
||
## 产物验证
|
||
|
||
```bash
|
||
npm run release:preflight:mac
|
||
npm run release:verify:mac
|
||
|
||
npm run release:preflight:win
|
||
npm run release:verify:win
|
||
```
|
||
|
||
验证脚本检查架构、体积和安装包存在性。正式标签还会验证 macOS 签名/Gatekeeper 或 Windows Authenticode 签名。
|
||
|
||
安装包还必须包含 `ssh://` 协议注册。macOS 检查 `CFBundleURLTypes`,Windows 安装后检查当前用户 `Software\\Classes\\ssh` 并实际执行一次协议唤起。只验证配置文件不足以证明单实例事件交付正常。
|
||
|
||
## 发布前检查
|
||
|
||
1. `package.json`、`package-lock.json`、`src-tauri/Cargo.toml`、`Cargo.lock` 和 `tauri.conf.json` 版本一致。
|
||
2. `npm run acceptance:full` 通过。
|
||
3. 目标平台构建和签名通过。
|
||
4. 安装后完成输入框复制/粘贴、SFTP 双向拖拽、普通区域右键菜单、SSH/SFTP/代理/跳板和 `ssh://` 单实例唤起验收。
|
||
5. 大模型新配置必须先测试后保存;Agent CLI 必须固定当前 SSH 目标,每条命令确认后才执行,critical 命令不得放行。
|
||
6. 检查安装包尺寸,没有上传 `rw.*.dmg`、日志、测试密钥或用户数据。
|
||
7. 保留上一稳定版本及回滚说明。
|