build(release): 加固 v0.1.0 桌面发布链路 (#3)
This commit is contained in:
@@ -66,8 +66,8 @@ Manual edits that leave these files inconsistent fail CI.
|
||||
## Stabilization Gates
|
||||
|
||||
Client builds require Node.js 22.13.0 or newer. The development frontend container,
|
||||
Web CI, macOS release candidates, Windows internal validation, and the production
|
||||
Web image use the same Node 22.13 baseline.
|
||||
Web CI, macOS and Windows release candidates, Windows internal validation, and the
|
||||
production Web image use the same Node 22.13 baseline.
|
||||
|
||||
Client release candidates must pass the shared Web checks and the Desktop
|
||||
release/security gate before promotion:
|
||||
@@ -85,8 +85,9 @@ npm run build
|
||||
npm run desktop:build:app
|
||||
```
|
||||
|
||||
`release:env:check` verifies build channel and commit metadata, and can be
|
||||
made strict for signed Desktop builds with `REQUIRE_DESKTOP_SIGNING=true`.
|
||||
`release:env:check` verifies build channel and commit metadata, and becomes
|
||||
platform-strict with `REQUIRE_DESKTOP_SIGNING=true` on macOS or
|
||||
`REQUIRE_WINDOWS_SIGNING=true` on Windows.
|
||||
`desktop:release:check` statically verifies the Tauri bundle, updater public
|
||||
key, CSP, capability scopes, command allowlist, query-token ban, generic system
|
||||
notification boundary, CI gate coverage, and secure session token boundary. The
|
||||
@@ -96,7 +97,7 @@ full manual release, security, regression, and Desktop UX checklist lives in
|
||||
## Promotion
|
||||
|
||||
1. Merge feature branches into `dev`.
|
||||
2. Require the shared client/Web and macOS Desktop CI jobs to pass.
|
||||
2. Require the shared client/Web and macOS/Windows Desktop CI jobs to pass.
|
||||
3. Promote the accepted scope from `dev` to `main`.
|
||||
4. Set the release version and complete regression testing on `main`.
|
||||
5. Promote `main` to `release`.
|
||||
@@ -130,11 +131,11 @@ for `localhost`, `127.0.0.1`, or `::1`.
|
||||
The release pipeline must:
|
||||
|
||||
1. build from the accepted release tag and commit;
|
||||
2. build macOS Universal desktop artifacts;
|
||||
3. sign and notarize the macOS app;
|
||||
4. produce updater artifacts and `.sig` files with the updater private key;
|
||||
5. generate `latest.json` and a checksum manifest with `npm run desktop:update-feed:create`;
|
||||
6. verify the feed with `npm run desktop:update-feed:check -- --feed <release-dir>/latest.json --artifacts-dir <release-dir>`;
|
||||
2. build the Universal macOS app/DMG and Windows x64 NSIS installer from that tag;
|
||||
3. sign and notarize macOS, and Authenticode-sign Windows with an RFC 3161 timestamp;
|
||||
4. produce macOS `.app.tar.gz` and Windows `.nsis.zip` updater artifacts plus their `.sig` files with the shared updater private key;
|
||||
5. generate one combined `latest.json` and checksum manifest with `npm run desktop:update-feed:create`;
|
||||
6. verify all macOS and Windows entries with `npm run desktop:update-feed:check -- --feed <release-dir>/latest.json --artifacts-dir <release-dir> --require-platform windows-x86_64`;
|
||||
7. upload immutable artifacts first;
|
||||
8. atomically replace `latest.json` last.
|
||||
|
||||
@@ -142,6 +143,10 @@ For Universal macOS artifacts, `latest.json` must provide both
|
||||
`darwin-aarch64` and `darwin-x86_64` entries pointing at the same Universal
|
||||
update package.
|
||||
|
||||
The same feed must also contain `windows-x86_64`, pointing to the signed NSIS
|
||||
`.nsis.zip` updater package. The Windows `.exe` installer is distributed next
|
||||
to the updater package but is not used as the updater URL.
|
||||
|
||||
The signed release candidate workflow lives at
|
||||
`.github/workflows/desktop-release-candidate.yml`. It must be run from a
|
||||
matching `vX.Y.Z` tag and produces a verified release directory as a GitHub
|
||||
@@ -149,21 +154,30 @@ artifact. That artifact is still only a release candidate; the release owner
|
||||
must upload immutable files to the production download origin and replace
|
||||
`latest.json` atomically after validation.
|
||||
|
||||
## Windows Build Readiness
|
||||
## Windows Release and Internal Validation
|
||||
|
||||
Second-phase Windows work is limited to CI compatibility validation. A
|
||||
`windows-latest` x64 NSIS build may be produced for verification, but it is not
|
||||
a formal deliverable until Windows code signing and release support are
|
||||
approved.
|
||||
Windows x64 NSIS is an approved formal Desktop target. Formal Windows builds
|
||||
run in `.github/workflows/desktop-release-candidate.yml` from the same exact
|
||||
`vX.Y.Z` tag and SHA as Web and macOS. They must:
|
||||
|
||||
Windows validation must cover:
|
||||
- import a Base64-encoded PFX from `WINDOWS_CERTIFICATE` using
|
||||
`WINDOWS_CERTIFICATE_PASSWORD`;
|
||||
- configure the imported certificate thumbprint, SHA-256 digest,
|
||||
`WINDOWS_TIMESTAMP_URL`, and RFC 3161 timestamp mode dynamically in CI;
|
||||
- set `REQUIRE_WINDOWS_SIGNING=true` and use the updater signing secrets;
|
||||
- verify the application and installer with `Get-AuthenticodeSignature`,
|
||||
including signer and timestamp certificates;
|
||||
- publish the signed NSIS `.exe`, `.nsis.zip`, and `.nsis.zip.sig` into the
|
||||
combined verified Desktop release directory.
|
||||
|
||||
Windows release validation also covers:
|
||||
|
||||
- WebView2 runtime prerequisite behavior;
|
||||
- user-level installer assumptions;
|
||||
- Windows Credential Manager session storage;
|
||||
- path handling and temporary file cleanup;
|
||||
- notification and updater compilation;
|
||||
- future code-signing requirements.
|
||||
- code-signing trust, timestamp validity, and updater signature verification.
|
||||
|
||||
The manual internal Windows validation workflow lives at
|
||||
`.github/workflows/desktop-windows-internal.yml`. It is `workflow_dispatch`
|
||||
@@ -173,7 +187,24 @@ and Desktop safety gates, builds an unsigned NSIS installer with updater
|
||||
artifacts disabled, and uploads the `.exe` plus `SHA256SUMS.txt` as a GitHub
|
||||
Actions artifact. This workflow is for internal compatibility verification
|
||||
only; it must not generate `latest.json`, update feeds, signed release
|
||||
directories, or formal Windows release artifacts.
|
||||
directories, or formal Windows release artifacts. A successful internal build
|
||||
does not substitute for the signed tag-only release workflow.
|
||||
|
||||
The formal workflow requires these organization settings:
|
||||
|
||||
- secrets: `TAURI_SIGNING_PRIVATE_KEY`,
|
||||
`TAURI_SIGNING_PRIVATE_KEY_PASSWORD`, `WINDOWS_CERTIFICATE`, and
|
||||
`WINDOWS_CERTIFICATE_PASSWORD`;
|
||||
- variable: `WINDOWS_TIMESTAMP_URL`;
|
||||
- shared versioned HTTPS artifact prefix: `DESKTOP_UPDATE_BASE_URL` or the
|
||||
manual workflow input.
|
||||
|
||||
The checked-in workflow implements the exportable PFX path. Confirm that the
|
||||
organization's certificate policy permits an exportable CI certificate before
|
||||
provisioning it. If the selected CA provides only hardware- or cloud-backed
|
||||
keys, replace the PFX import with a reviewed Tauri `signCommand` integration
|
||||
(for example, the organization's Azure signing provider) while retaining the
|
||||
same Authenticode and timestamp verification gates.
|
||||
|
||||
## Required Checks
|
||||
|
||||
@@ -197,11 +228,12 @@ export REQUIRE_DESKTOP_SIGNING=true
|
||||
npm run release:env:check
|
||||
npm run desktop:release-readiness:check
|
||||
npm run desktop:build:macos-release -- --ci
|
||||
npm run desktop:update-feed:create -- --artifact <CTMS.app.tar.gz> --base-url <versioned-https-artifact-prefix> --output-dir <release-dir>
|
||||
npm run desktop:update-feed:check -- --feed <release-dir>/latest.json --artifacts-dir <release-dir>
|
||||
npm run desktop:update-feed:create -- --artifact <CTMS.app.tar.gz> --platform-artifact windows-x86_64=<CTMS.nsis.zip> --include <CTMS.dmg> --include <CTMS-installer.exe> --base-url <versioned-https-artifact-prefix> --output-dir <release-dir>
|
||||
npm run desktop:update-feed:check -- --feed <release-dir>/latest.json --artifacts-dir <release-dir> --require-platform windows-x86_64
|
||||
```
|
||||
|
||||
The Desktop build must run on macOS for the current first-phase target. A signed
|
||||
or notarized public release additionally requires the Apple credentials defined
|
||||
by the release owner. A formal second-phase desktop release also requires the
|
||||
updater signing key; unsigned internal builds are not formal distributions.
|
||||
The macOS and Windows signed builds run in their native CI jobs. macOS requires
|
||||
the Apple signing/notarization credentials defined by the release owner;
|
||||
Windows requires the PFX certificate/password and timestamp URL above. Both use
|
||||
the same updater signing key and are aggregated only after both native jobs
|
||||
pass. Unsigned internal builds are not formal distributions.
|
||||
|
||||
Reference in New Issue
Block a user