build(release): stage local macOS v0.1.0 distribution
This commit is contained in:
Cheng Zhou
@@ -88,7 +88,8 @@ npm run desktop:build:app
|
||||
| 登录与项目恢复 | 必测 | 必测 | 登录成功后恢复可访问项目；401 后重新登录 |
|
||||
| 记住密码 | 必测 | 必测 | Web 使用浏览器凭据管理/自动填充；Desktop 使用系统凭据库；未勾选时不继续写入保存密码 |
|
||||
| 30 天免登录 | 不适用 | 必测 | 关闭并重启 App 后复用系统凭据库中的后端在线会话；超过 30 天或 `/me` 校验失败后重新登录 |
|
||||
| 服务器地址未配置 | 不适用 | 必测 | 自动进入服务器设置，不进入业务页 |
|
||||
| 构建默认服务器地址已注入 | 不适用 | 必测 | 首次启动使用 `VITE_DESKTOP_SERVER_URL`，不要求重复输入；运行时代码不含生产域名 |
|
||||
| 构建默认地址和本地配置均缺失 | 不适用 | 必测 | 自动进入服务器设置，不进入业务页 |
|
||||
| 服务器地址切换 | 不适用 | 必测 | 清除当前会话和项目上下文，要求重新登录 |
|
||||
| 服务端不可达 | 必测 | 必测 | 显示可恢复错误，不进入离线模式 |
|
||||
| 本地缓存命中 | 必测 | 必测 | `/me` 校验通过后可先展示缓存再后台刷新 |
|
||||
@@ -288,6 +289,9 @@ npm run desktop:build:app
|
||||
- macOS 使用 Tauri `signingIdentity: "-"` 生成 ad-hoc 签名 Universal app/DMG，必须通过 `codesign --verify` 并确认 `Signature=adhoc`，不执行或声称 Apple 公证。
|
||||
- Windows 应用和 NSIS 安装器不做 Authenticode 签名，必须通过 `Get-AuthenticodeSignature` 确认 `NotSigned`，不执行或声称 RFC 3161 时间戳。
|
||||
- 两端仍必须从同一 `v0.1.0` tag 和 SHA 构建，使用同一 updater 私钥生成 `.sig`，并通过联合 feed、checksum 和 provenance 校验。
|
||||
- GitHub Actions 额度不可用期间，发布负责人额外批准从最终 `v0.1.0` tag/SHA 在受控 macOS 主机本地构建并先行上传 macOS 制品；Windows 必须在恢复后从同一 tag/SHA 后补。
|
||||
- macOS 先行 Release 必须包含 DMG、updater 包及 `.sig`、checksum、provenance、`UNSIGNED-PLATFORM` 和 Windows pending 说明，且不得包含或替换生产 `latest.json`。
|
||||
- Windows `NotSigned` 实物和联合 feed 全部验证通过后，才允许激活生产 updater feed；tag 不得为补充 Windows 制品而移动。
|
||||
- 制品与 Actions artifact 名称必须含 `_UNSIGNED` 或 `UNSIGNED-PLATFORM`，发布目录必须携带 `UNSIGNED-PLATFORM-RELEASE.txt` 和 `DESKTOP-RELEASE-PROVENANCE.json`。
|
||||
- 受控分发说明必须明确提示 macOS Gatekeeper 与 Windows SmartScreen 警告；平台未签名制品不得描述为 Apple/Microsoft 信任或已公证/已 Authenticode 签名。
|
||||
|
||||
|
||||
@@ -317,6 +317,15 @@ Platform signing remains the default for versions without an exact approved
|
||||
exception. An exception never permits disabling Tauri updater signatures or
|
||||
building Web, macOS, and Windows from different tags or commits.
|
||||
|
||||
For v0.1.0 only, the release owner also approved a staged contingency while
|
||||
hosted Actions capacity is unavailable: macOS may be built on a controlled
|
||||
local macOS host from the immutable final `v0.1.0` tag and published first.
|
||||
Windows remains pending and must later be built from that same tag and SHA.
|
||||
The macOS-only release must carry checksums, provenance, updater signature,
|
||||
platform-trust warnings, and an explicit Windows-pending notice. It must not
|
||||
publish or replace production `latest.json`; updater feed activation waits for
|
||||
combined macOS and Windows verification.
|
||||
|
||||
Reference:
|
||||
|
||||
- [docs/guides/release-checklist.md](guides/release-checklist.md)
|
||||
|
||||
@@ -108,6 +108,8 @@ npm run desktop:build:app
|
||||
|
||||
正式桌面发布构建必须从同一正式 tag 分别在 macOS 和 Windows 原生 CI job 执行。两端都必须设置 updater 签名私钥，updater 签名不可关闭。平台签名默认路径仍要求 macOS 设置 Apple 签名/公证变量并以 `REQUIRE_DESKTOP_SIGNING=true` 执行，Windows 设置 PFX、密码和 RFC 3161 时间戳变量并以 `REQUIRE_WINDOWS_SIGNING=true` 执行。只有 `frontend/desktop-release-policy.json` 对当前精确版本存在已批准例外时，workflow 才可改为 macOS ad-hoc、Windows Authenticode 未签名路径；例外制品必须标注 `UNSIGNED-PLATFORM`、生成 provenance 和风险说明。两个平台与联合 feed 校验通过后才能汇总正式 updater feed。
|
||||
|
||||
v0.1.0 额外批准 GitHub Actions 额度不可用时的分阶段应急路径：先在受控 macOS 主机从最终、不可移动的 `v0.1.0` tag/SHA 本地构建并上传 macOS ad-hoc 制品，随附 updater `.sig`、checksum、provenance、平台未签名警告和 Windows pending 说明；Windows 恢复后必须从同一 tag/SHA 后补。macOS 先行阶段不得发布或替换生产 `latest.json`，联合 feed 必须等待 Windows `NotSigned` 实物验证完成。
|
||||
|
||||
后端改动应补充执行受影响模块的后端测试、迁移检查和接口回归。
|
||||
|
||||
### 4. 创建提交
|
||||
@@ -297,6 +299,8 @@ git push origin v1.2.0
|
||||
|
||||
网页端、macOS 和 Windows 桌面端必须从同一个 `v1.2.0` 标签构建。不得从不同分支、不同提交或本地未提交状态构建正式制品。两个平台的 updater 签名制品必须始终验证通过；macOS 签名/公证和 Windows 代码签名/RFC 3161 时间戳必须验证通过，除非 `frontend/desktop-release-policy.json` 对该精确版本记录了已批准例外。采用例外时必须验证 macOS 确为 ad-hoc、Windows 确为 `NotSigned`，并随安装包分发 `UNSIGNED-PLATFORM` 风险说明、provenance 和 checksum，之后才能最后原子替换生产 `latest.json`。
|
||||
|
||||
若执行 v0.1.0 的已批准分阶段应急路径，首次 macOS Release 可先于 Windows 发布，但 tag/SHA 不得移动；首次 Release 不包含 `latest.json`，并必须明确标记 Windows pending。Windows 后补且联合 feed 验证通过后，才允许按上述顺序激活生产 updater feed。
|
||||
|
||||
发布记录至少包含：
|
||||
|
||||
- 产品版本号
|
||||
|
||||
@@ -169,6 +169,21 @@ and release directory contain `UNSIGNED-PLATFORM`; the directory must include
|
||||
and Gatekeeper or SmartScreen warnings are expected. Later versions return to
|
||||
the signed default unless separately approved.
|
||||
|
||||
### v0.1.0 staged macOS contingency
|
||||
|
||||
The release owner approved one additional v0.1.0 contingency for unavailable
|
||||
hosted Actions capacity. A controlled local macOS host may build the macOS
|
||||
ad-hoc artifacts from the immutable final `v0.1.0` tag and publish them first.
|
||||
That initial GitHub Release must include the DMG, updater package and `.sig`,
|
||||
`SHA256SUMS.txt`, provenance, the unsigned-platform warning, and an explicit
|
||||
Windows-pending notice. Windows must later be built from the same tag and SHA.
|
||||
|
||||
The staged macOS release is an installer distribution, not an activated
|
||||
cross-platform updater release. Do not upload or replace production
|
||||
`latest.json` until the Windows `NotSigned` installer/updater has been built and
|
||||
the combined macOS/Windows feed passes full verification. This fallback is
|
||||
limited to v0.1.0 and does not authorize local formal builds for later versions.
|
||||
|
||||
## Windows Release and Internal Validation
|
||||
|
||||
Windows x64 NSIS is an approved formal Desktop target. Formal Windows builds
|
||||
@@ -216,9 +231,19 @@ The formal workflow always requires these organization settings:
|
||||
|
||||
- secrets: `TAURI_SIGNING_PRIVATE_KEY` and
|
||||
`TAURI_SIGNING_PRIVATE_KEY_PASSWORD`;
|
||||
- client default CTMS origin: repository variable `VITE_DESKTOP_SERVER_URL`;
|
||||
- shared versioned HTTPS artifact prefix: `DESKTOP_UPDATE_BASE_URL` or the
|
||||
manual workflow input.
|
||||
|
||||
`VITE_DESKTOP_SERVER_URL` must be an HTTPS origin without credentials, path,
|
||||
query, or fragment. Vite embeds it as the Desktop client's first-run default;
|
||||
the runtime source must not contain the production hostname. A user can still
|
||||
override this default in Desktop server settings, where the persisted manual
|
||||
value takes precedence and switching origins clears the existing session and
|
||||
server-scoped client state. Do not reuse this value as
|
||||
`DESKTOP_UPDATE_BASE_URL`: the latter points to immutable updater artifacts,
|
||||
not the CTMS business API.
|
||||
|
||||
The default signed path additionally requires `WINDOWS_CERTIFICATE`,
|
||||
`WINDOWS_CERTIFICATE_PASSWORD`, and `WINDOWS_TIMESTAMP_URL`, plus the Apple
|
||||
credentials documented by the release owner. The v0.1.0 exception does not
|
||||
@@ -239,6 +264,7 @@ npm ci
|
||||
npm run version:check
|
||||
export VITE_BUILD_CHANNEL=release
|
||||
export VITE_BUILD_COMMIT="$(git rev-parse HEAD)"
|
||||
export VITE_DESKTOP_SERVER_URL="https://ctms.example.com"
|
||||
npm run release:env:check
|
||||
npm run runtime:check
|
||||
npm run desktop:release:check
|
||||
|
||||
Reference in New Issue
Block a user