fix(updater): 同步 updater pubkey 与新签名密钥对 - #73
Open
veyvin wants to merge 13 commits into
Open
Conversation
Co-authored-by: traeagent <traeagent@users.noreply.github.com>
feat: 执行 Release 结果
Co-authored-by: traeagent <traeagent@users.noreply.github.com>
feat: 增强 release 工作流以确保 git 标签可用
Co-authored-by: traeagent <traeagent@users.noreply.github.com>
chore: upgrade Node.js to v22 in CI workflows
pnpm latest (11) ignores dependency build scripts by default, which fails husky prepare during install. Also disable husky in CI and whitelist native build deps for future pnpm 10+. Co-authored-by: Cursor <cursoragent@cursor.com>
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
ci: add TAURI_UPDATER_* secrets to tauri-action workflow
Co-authored-by: traeagent <traeagent@users.noreply.github.com>
ci: fix tauri updater signing by removing invalid TAURI_UPDATER_* env
Co-authored-by: traeagent <traeagent@users.noreply.github.com>
Reviewer's Guide更新 Tauri 更新器签名配置和发布工作流，以对齐 Tauri v2 的单行 base64 签名密钥，同时让发布流程可通过 File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your Experience访问你的 dashboard 以：
Getting HelpOriginal review guide in EnglishReviewer's GuideUpdates Tauri updater signing configuration and release workflows to align with Tauri v2’s single-line base64 signing keys, while making releases runnable via workflow_dispatch and compatible with pnpm 9 and Node 22. File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - 我发现了 1 个问题，并留下了一些整体性反馈：
workflow_dispatch的输入version目前只在run-name中使用，而没有参与标签/版本解析逻辑，这可能会让期望用它来控制发布版本的调用方感到困惑；建议要么将它接入版本/标签选择逻辑，要么直接移除以避免歧义。publish-tauri和publish-webview2-fixed这两个 job 现在有相当多重复的初始化逻辑（checkout、pnpm/node 设置、tag-sync 步骤、Husky 环境）；建议把这些抽取到一个可复用的 workflow 或 composite action 中，这样未来的更改可以集中在一个地方。
给 AI Agent 的提示
Please address the comments from this code review:
## Overall Comments
- The `workflow_dispatch` input `version` is only used in `run-name` and not in the tag/version resolution logic, which may confuse callers expecting it to control the release version; consider either wiring it into the version/tag selection or removing it to avoid ambiguity.
- The `publish-tauri` and `publish-webview2-fixed` jobs now share quite a bit of duplicated setup logic (checkout, pnpm/node setup, tag-sync step, Husky env); consider extracting these into a reusable workflow or composite action to keep future changes in one place.
## Individual Comments
### Comment 1
<location path=".github/workflows/release.yml" line_range="7-9" />
<code_context>
on:
workflow_dispatch:
+ inputs:
+ version:
+ description: 'Release version (e.g., v1.0.0). If empty, uses package.json version'
+ required: false
push:
</code_context>
<issue_to_address>
**suggestion (bug_risk):** The `version` workflow input is only used for the run-name and not for determining the actual release/tag version.
This behavior doesn’t match the input description and may suggest to users that `version` controls the release/tag version when it doesn’t. Please either route `inputs.version` into the `Get Version` logic (preferring it when set) or update the description so it accurately reflects that the version always comes from `package.json`.
```suggestion
version:
description: 'Optional label for this manual release run (used in run name only). Release/tag version always comes from package.json.'
required: false
```
</issue_to_address>帮我变得更有用！请对每条评论点 👍 或 👎，我会根据你的反馈改进之后的评审。
Original comment in English
Hey - I've found 1 issue, and left some high level feedback:
- The
workflow_dispatchinputversionis only used inrun-nameand not in the tag/version resolution logic, which may confuse callers expecting it to control the release version; consider either wiring it into the version/tag selection or removing it to avoid ambiguity. - The
publish-tauriandpublish-webview2-fixedjobs now share quite a bit of duplicated setup logic (checkout, pnpm/node setup, tag-sync step, Husky env); consider extracting these into a reusable workflow or composite action to keep future changes in one place.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The `workflow_dispatch` input `version` is only used in `run-name` and not in the tag/version resolution logic, which may confuse callers expecting it to control the release version; consider either wiring it into the version/tag selection or removing it to avoid ambiguity.
- The `publish-tauri` and `publish-webview2-fixed` jobs now share quite a bit of duplicated setup logic (checkout, pnpm/node setup, tag-sync step, Husky env); consider extracting these into a reusable workflow or composite action to keep future changes in one place.
## Individual Comments
### Comment 1
<location path=".github/workflows/release.yml" line_range="7-9" />
<code_context>
on:
workflow_dispatch:
+ inputs:
+ version:
+ description: 'Release version (e.g., v1.0.0). If empty, uses package.json version'
+ required: false
push:
</code_context>
<issue_to_address>
**suggestion (bug_risk):** The `version` workflow input is only used for the run-name and not for determining the actual release/tag version.
This behavior doesn’t match the input description and may suggest to users that `version` controls the release/tag version when it doesn’t. Please either route `inputs.version` into the `Get Version` logic (preferring it when set) or update the description so it accurately reflects that the version always comes from `package.json`.
```suggestion
version:
description: 'Optional label for this manual release run (used in run name only). Release/tag version always comes from package.json.'
required: false
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Comment on lines
+7
to
+9
| version: | ||
| description: 'Release version (e.g., v1.0.0). If empty, uses package.json version' | ||
| required: false |
There was a problem hiding this comment.
suggestion (bug_risk): version 这个 workflow 输入目前只用于 run-name，而不会用来决定实际的发布/标签版本。
这种行为与输入描述不符，也可能会让用户误以为 version 会控制发布/标签版本，而事实并非如此。请考虑要么将 inputs.version 接入 Get Version 逻辑（在其被设置时优先使用），要么更新描述，使其准确表达版本始终来自 package.json。
Suggested change
| version: | |
| description: 'Release version (e.g., v1.0.0). If empty, uses package.json version' | |
| required: false | |
| version: | |
| description: 'Optional label for this manual release run (used in run name only). Release/tag version always comes from package.json.' | |
| required: false |
Original comment in English
suggestion (bug_risk): The version workflow input is only used for the run-name and not for determining the actual release/tag version.
This behavior doesn’t match the input description and may suggest to users that version controls the release/tag version when it doesn’t. Please either route inputs.version into the Get Version logic (preferring it when set) or update the description so it accurately reflects that the version always comes from package.json.
Suggested change
| version: | |
| description: 'Release version (e.g., v1.0.0). If empty, uses package.json version' | |
| required: false | |
| version: | |
| description: 'Optional label for this manual release run (used in run name only). Release/tag version always comes from package.json.' | |
| required: false |
Co-authored-by: traeagent <traeagent@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
背景
打包 workflow 报错 `TAURI_UPDATER_PRIVATE_KEY does NOT contain a 4-line private key`，根因是 Tauri v2 的签名密钥格式已从 v1 的多行 minisign 文件改为单行 base64 字符串，而旧的诊断步骤仍按 v1 的"4 行"标准校验，导致即使 secret 正确也被 `exit 1` 拦截。
改动
关联操作（需仓库管理员在 GitHub Settings 中执行）
在 `Settings → Secrets and variables → Actions` 配置以下三个 secret（均为单行 base64，整段粘贴，不要去掉换行）：
Summary by Sourcery
更新 Tauri 更新器签名配置，并现代化 CI 发布工作流，以支持手动和基于标签的发布，同时确保构建可靠。
新功能：
workflow_dispatch允许手动触发发布运行，支持可选版本输入，并动态设置运行名称。错误修复：
增强：
pnpm固定到版本 9，并配置onlyBuiltDependencies，以在新版pnpm行为下确保所需的原生构建依赖被正确安装。depth 0），以支持依赖仓库历史的打标签和发布任务。CI：
Original summary in English
Summary by Sourcery
Update Tauri updater signing configuration and modernize CI release workflows to support manual and tag-based releases with reliable builds.
New Features:
Bug Fixes:
Enhancements:
CI: