Repository navigation
ci(release): 用 git-cliff 自动生成 GitHub Release 更新日志 - #43
Merged
Merged
Conversation
CI 发版时 GitHub Release 正文只有一段静态的安装说明，看不出这个版本 到底改了什么。接入 git-cliff，让每次发版自动按 conventional commits 汇总本次变更。 - .github/cliff.toml：参考 MAAGC 的配置改写，按 commit 前缀分组 （新功能 / Bug修复 / 文档 / 性能优化 / 重构 / 日常维护 / CI 等）， 正文带上 scope 与 GitHub 用户名，首次贡献者单列一节，尾部附安装与 使用命令 - publish.yml：新增 changelog job，checkout 完整历史与 tag，用 --current 生成「属于当前 tag 的提交」这一段；正式版额外用 --tag-pattern 把基线锁定在上一个正式版，这样 beta 期间的提交也会 并入本次说明；预发布版不加该参数 - 生成失败时退回静态安装说明（continue-on-error + fallback），不阻塞发版 - 顺带修掉旧写法里 YAML 双引号标量把换行折叠掉、导致 Release 正文 的代码块挤成一行的问题 验证： - actionlint 1.7.12 无告警 - git-cliff 2.14.2 在真实仓库（含 detached HEAD 于 tag 的检出）跑通， v1.3.0 输出与预期一致 - 预发布路径（不加 --tag-pattern）同样验证通过
git-cliff 会调用 GitHub API 拉取 PR 元数据做贡献者统计，默认 token 权限 不足时该请求返回 403，git-cliff 直接 panic 而非优雅降级。 显式声明 contents: read（checkout）+ pull-requests: read（PR 元数据）， 让权限需求可见且最小化。
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
嗨——我发现了 6 个问题
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path=".github/workflows/publish.yml" line_range="29" />
<code_context>
+ - name: Determine release tag
+ id: meta
+ run: |
+ tag="${{ inputs.tag || github.ref_name }}"
+ echo "tag=$tag" >> "$GITHUB_OUTPUT"
+ if [[ "$tag" =~ ^v[0-9]+[.][0-9]+[.][0-9]+$ ]]; then
</code_context>
<issue_to_address>
**Tag input executes shell commands**
When a supplied or pushed tag contains shell syntax, bash parses the interpolated tag as script source before assigning `tag`, and the fallback command repeats that interpolation, so shell commands run on the changelog runner and can access its credentials or environment.
Pass the tag through an environment variable and use it as data in both commands.
Also at `.github/workflows/publish.yml:61-63`.
</issue_to_address>
### Comment 2
<location path=".github/workflows/publish.yml" line_range="21" />
<code_context>
+ release_body: ${{ steps.git-cliff.outputs.content || steps.fallback.outputs.body }}
+ steps:
+ - name: Checkout
+ uses: actions/checkout@v4
+ with:
+ fetch-depth: 0 # git-cliff 需要完整历史与 tag 才能算出版本区间
</code_context>
<issue_to_address>
**Mutable action exposes checkout token**
When the upstream action tag is compromised or retargeted to malicious code, `orhun/git-cliff-action@v4` runs after checkout, which persists its credential in the repository’s Git config by default; compromised or retargeted action code can read and exfiltrate the job token, then use whatever repository permissions it has.
Pin the action to a reviewed full commit SHA, set the job’s minimum required token permissions, and disable checkout credential persistence if the action does not need Git credentials.
Also at `.github/workflows/publish.yml:38`.
</issue_to_address>
### Comment 3
<location path=".github/workflows/publish.yml" line_range="24" />
<code_context>
+ uses: actions/checkout@v4
+ with:
+ fetch-depth: 0 # git-cliff 需要完整历史与 tag 才能算出版本区间
+ ref: ${{ inputs.tag || github.ref }} # 检出版本对应的 tag，--current 才有归属
+
+ - name: Determine release tag
</code_context>
<issue_to_address>
**Release artifacts use different code**
When a manual dispatch supplies a tag that differs from the workflow ref, the changelog job checks out the requested tag, but the `build` job checks out the workflow ref, so the release notes describe different code from the package and artifacts published under that tag.
Make the `build` job check out the same requested tag used by the changelog job.
</issue_to_address>
### Comment 4
<location path=".github/workflows/publish.yml" line_range="24" />
<code_context>
+ uses: actions/checkout@v4
+ with:
+ fetch-depth: 0 # git-cliff 需要完整历史与 tag 才能算出版本区间
+ ref: ${{ inputs.tag || github.ref }} # 检出版本对应的 tag，--current 才有归属
+
+ - name: Determine release tag
</code_context>
<issue_to_address>
**New manual tags block publishing**
When a workflow_dispatch run supplies a new tag name that has not been pushed yet, `actions/checkout` fails before the git-cliff fallback runs, and `build` is blocked by `needs: changelog`; the manually requested release therefore never builds or publishes.
For manual runs, check out the dispatch ref when the requested tag does not exist, or ensure the tag exists before starting the workflow.
</issue_to_address>
### Comment 5
<location path=".github/cliff.toml" line_range="116" />
<code_context>
+
+# 启用GitHub集成
+[git.github]
+commits = true
</code_context>
<issue_to_address>
**API throttling drops the changelog**
When gitHub API requests from the runner exceed the unauthenticated rate limit, the GitHub integration needs API access for commit metadata, but the job passes only `GITHUB_REPO` and no token. Once unauthenticated API requests are rate-limited, git-cliff fails and `continue-on-error` makes the release use only the static fallback, losing the change summary.
Pass `${{ secrets.GITHUB_TOKEN }}` to the git-cliff step as `GITHUB_TOKEN`.
Also at `.github/workflows/publish.yml:52`.
</issue_to_address>
### Comment 6
<location path=".github/cliff.toml" line_range="74" />
<code_context>
+# 安装
+
+```sh
+pip install maa-mcp=={{ latest_version }}
+```
+
</code_context>
<issue_to_address>
**Install command uses invalid version**
When a release tag uses the `v` prefix, as the workflow’s formal-release tag pattern expects, the generated footer and fallback retain the `v` prefix, so pip looks for a package version such as `v1.3.0` instead of the published `1.3.0`; release readers following either installation command cannot install that version.
Strip the leading `v` from the tag-derived version in both installation commands.
Also at `.github/workflows/publish.yml:63`.
</issue_to_address>Original comment in English
Hey - I've found 6 issues
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path=".github/workflows/publish.yml" line_range="29" />
<code_context>
+ - name: Determine release tag
+ id: meta
+ run: |
+ tag="${{ inputs.tag || github.ref_name }}"
+ echo "tag=$tag" >> "$GITHUB_OUTPUT"
+ if [[ "$tag" =~ ^v[0-9]+[.][0-9]+[.][0-9]+$ ]]; then
</code_context>
<issue_to_address>
**Tag input executes shell commands**
When a supplied or pushed tag contains shell syntax, bash parses the interpolated tag as script source before assigning `tag`, and the fallback command repeats that interpolation, so shell commands run on the changelog runner and can access its credentials or environment.
Pass the tag through an environment variable and use it as data in both commands.
Also at `.github/workflows/publish.yml:61-63`.
</issue_to_address>
### Comment 2
<location path=".github/workflows/publish.yml" line_range="21" />
<code_context>
+ release_body: ${{ steps.git-cliff.outputs.content || steps.fallback.outputs.body }}
+ steps:
+ - name: Checkout
+ uses: actions/checkout@v4
+ with:
+ fetch-depth: 0 # git-cliff 需要完整历史与 tag 才能算出版本区间
</code_context>
<issue_to_address>
**Mutable action exposes checkout token**
When the upstream action tag is compromised or retargeted to malicious code, `orhun/git-cliff-action@v4` runs after checkout, which persists its credential in the repository’s Git config by default; compromised or retargeted action code can read and exfiltrate the job token, then use whatever repository permissions it has.
Pin the action to a reviewed full commit SHA, set the job’s minimum required token permissions, and disable checkout credential persistence if the action does not need Git credentials.
Also at `.github/workflows/publish.yml:38`.
</issue_to_address>
### Comment 3
<location path=".github/workflows/publish.yml" line_range="24" />
<code_context>
+ uses: actions/checkout@v4
+ with:
+ fetch-depth: 0 # git-cliff 需要完整历史与 tag 才能算出版本区间
+ ref: ${{ inputs.tag || github.ref }} # 检出版本对应的 tag，--current 才有归属
+
+ - name: Determine release tag
</code_context>
<issue_to_address>
**Release artifacts use different code**
When a manual dispatch supplies a tag that differs from the workflow ref, the changelog job checks out the requested tag, but the `build` job checks out the workflow ref, so the release notes describe different code from the package and artifacts published under that tag.
Make the `build` job check out the same requested tag used by the changelog job.
</issue_to_address>
### Comment 4
<location path=".github/workflows/publish.yml" line_range="24" />
<code_context>
+ uses: actions/checkout@v4
+ with:
+ fetch-depth: 0 # git-cliff 需要完整历史与 tag 才能算出版本区间
+ ref: ${{ inputs.tag || github.ref }} # 检出版本对应的 tag，--current 才有归属
+
+ - name: Determine release tag
</code_context>
<issue_to_address>
**New manual tags block publishing**
When a workflow_dispatch run supplies a new tag name that has not been pushed yet, `actions/checkout` fails before the git-cliff fallback runs, and `build` is blocked by `needs: changelog`; the manually requested release therefore never builds or publishes.
For manual runs, check out the dispatch ref when the requested tag does not exist, or ensure the tag exists before starting the workflow.
</issue_to_address>
### Comment 5
<location path=".github/cliff.toml" line_range="116" />
<code_context>
+
+# 启用GitHub集成
+[git.github]
+commits = true
</code_context>
<issue_to_address>
**API throttling drops the changelog**
When gitHub API requests from the runner exceed the unauthenticated rate limit, the GitHub integration needs API access for commit metadata, but the job passes only `GITHUB_REPO` and no token. Once unauthenticated API requests are rate-limited, git-cliff fails and `continue-on-error` makes the release use only the static fallback, losing the change summary.
Pass `${{ secrets.GITHUB_TOKEN }}` to the git-cliff step as `GITHUB_TOKEN`.
Also at `.github/workflows/publish.yml:52`.
</issue_to_address>
### Comment 6
<location path=".github/cliff.toml" line_range="74" />
<code_context>
+# 安装
+
+```sh
+pip install maa-mcp=={{ latest_version }}
+```
+
</code_context>
<issue_to_address>
**Install command uses invalid version**
When a release tag uses the `v` prefix, as the workflow’s formal-release tag pattern expects, the generated footer and fallback retain the `v` prefix, so pip looks for a package version such as `v1.3.0` instead of the published `1.3.0`; release readers following either installation command cannot install that version.
Strip the leading `v` from the tag-derived version in both installation commands.
Also at `.github/workflows/publish.yml:63`.
</issue_to_address>| - name: Determine release tag | ||
| id: meta | ||
| run: | | ||
| tag="${{ inputs.tag || github.ref_name }}" |
Contributor
There was a problem hiding this comment.
🟠 High · 标签输入会执行 Shell 命令
当提供或推送的标签包含 Shell 语法时，bash 会在赋值给 tag 之前，将插入的标签解析为脚本源码；后备命令也会再次进行相同的插值，因此 Shell 命令会在变更日志运行器上执行，并可访问其凭据或环境变量。
请通过环境变量传递标签，并在这两条命令中将其作为数据使用。
另见 .github/workflows/publish.yml:61-63。
给 AI 代理的提示
在 `.github/workflows/publish.yml` 第 29 行：
**标签输入会执行 Shell 命令**
当提供或推送的标签包含 Shell 语法时，bash 会在赋值给 `tag` 之前，将插入的标签解析为脚本源码；后备命令也会再次进行相同的插值，因此 Shell 命令会在变更日志运行器上执行，并可访问其凭据或环境变量。
请通过环境变量传递标签，并在这两条命令中将其作为数据使用。
另见 `.github/workflows/publish.yml:61-63`。Original comment in English
🟠 High · Tag input executes shell commands
When a supplied or pushed tag contains shell syntax, bash parses the interpolated tag as script source before assigning tag, and the fallback command repeats that interpolation, so shell commands run on the changelog runner and can access its credentials or environment.
Pass the tag through an environment variable and use it as data in both commands.
Also at .github/workflows/publish.yml:61-63.
Prompt for AI agents
In `.github/workflows/publish.yml` at line 29:
**Tag input executes shell commands**
When a supplied or pushed tag contains shell syntax, bash parses the interpolated tag as script source before assigning `tag`, and the fallback command repeats that interpolation, so shell commands run on the changelog runner and can access its credentials or environment.
Pass the tag through an environment variable and use it as data in both commands.
Also at `.github/workflows/publish.yml:61-63`.| release_body: ${{ steps.git-cliff.outputs.content || steps.fallback.outputs.body }} | ||
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@v4 |
Contributor
There was a problem hiding this comment.
🟡 Medium · 可变 Action 会暴露 checkout 令牌
当上游 Action 标签遭到入侵或被重新指向恶意代码时，orhun/git-cliff-action@v4 会在 checkout 后运行；而 checkout 默认会将其凭据持久化到仓库的 Git 配置中。遭入侵或被重新指向的 Action 代码可以读取并窃取作业令牌，随后利用它所拥有的仓库权限。
请将 Action 固定到经过审核的完整提交 SHA，设置作业所需的最低令牌权限；如果 Action 不需要 Git 凭据，请禁用 checkout 凭据持久化。
另见 .github/workflows/publish.yml:38。
给 AI 代理的提示
在 `.github/workflows/publish.yml` 第 21 行：
**可变 Action 会暴露 checkout 令牌**
当上游 Action 标签遭到入侵或被重新指向恶意代码时，`orhun/git-cliff-action@v4` 会在 checkout 后运行；而 checkout 默认会将其凭据持久化到仓库的 Git 配置中。遭入侵或被重新指向的 Action 代码可以读取并窃取作业令牌，随后利用它所拥有的仓库权限。
请将 Action 固定到经过审核的完整提交 SHA，设置作业所需的最低令牌权限；如果 Action 不需要 Git 凭据，请禁用 checkout 凭据持久化。
另见 `.github/workflows/publish.yml:38`。Original comment in English
🟡 Medium · Mutable action exposes checkout token
When the upstream action tag is compromised or retargeted to malicious code, orhun/git-cliff-action@v4 runs after checkout, which persists its credential in the repository’s Git config by default; compromised or retargeted action code can read and exfiltrate the job token, then use whatever repository permissions it has.
Pin the action to a reviewed full commit SHA, set the job’s minimum required token permissions, and disable checkout credential persistence if the action does not need Git credentials.
Also at .github/workflows/publish.yml:38.
Prompt for AI agents
In `.github/workflows/publish.yml` at line 21:
**Mutable action exposes checkout token**
When the upstream action tag is compromised or retargeted to malicious code, `orhun/git-cliff-action@v4` runs after checkout, which persists its credential in the repository’s Git config by default; compromised or retargeted action code can read and exfiltrate the job token, then use whatever repository permissions it has.
Pin the action to a reviewed full commit SHA, set the job’s minimum required token permissions, and disable checkout credential persistence if the action does not need Git credentials.
Also at `.github/workflows/publish.yml:38`.| uses: actions/checkout@v4 | ||
| with: | ||
| fetch-depth: 0 # git-cliff 需要完整历史与 tag 才能算出版本区间 | ||
| ref: ${{ inputs.tag || github.ref }} # 检出版本对应的 tag，--current 才有归属 |
Contributor
There was a problem hiding this comment.
🟠 High · 发布制品使用了不同的代码
当手动触发运行时提供的标签与工作流引用不同时，变更日志作业会检出指定标签，而 build 作业会检出工作流引用，因此发布说明描述的代码与以该标签发布的软件包和制品不一致。
请让 build 作业检出与变更日志作业相同的指定标签。
给 AI 代理的提示
在 `.github/workflows/publish.yml` 第 24 行：
**发布制品使用了不同的代码**
当手动触发运行时提供的标签与工作流引用不同时，变更日志作业会检出指定标签，而 `build` 作业会检出工作流引用，因此发布说明描述的代码与以该标签发布的软件包和制品不一致。
请让 `build` 作业检出与变更日志作业相同的指定标签。Original comment in English
🟠 High · Release artifacts use different code
When a manual dispatch supplies a tag that differs from the workflow ref, the changelog job checks out the requested tag, but the build job checks out the workflow ref, so the release notes describe different code from the package and artifacts published under that tag.
Make the build job check out the same requested tag used by the changelog job.
Prompt for AI agents
In `.github/workflows/publish.yml` at line 24:
**Release artifacts use different code**
When a manual dispatch supplies a tag that differs from the workflow ref, the changelog job checks out the requested tag, but the `build` job checks out the workflow ref, so the release notes describe different code from the package and artifacts published under that tag.
Make the `build` job check out the same requested tag used by the changelog job.| uses: actions/checkout@v4 | ||
| with: | ||
| fetch-depth: 0 # git-cliff 需要完整历史与 tag 才能算出版本区间 | ||
| ref: ${{ inputs.tag || github.ref }} # 检出版本对应的 tag，--current 才有归属 |
Contributor
There was a problem hiding this comment.
🟡 Medium · 新的手动标签会阻止发布
当 workflow_dispatch 运行提供尚未推送的新标签名称时，actions/checkout 会在 git-cliff 的后备逻辑运行之前失败，而 build 会因 needs: changelog 被阻止；因此，手动请求的发布既不会构建，也不会发布。
对于手动运行，如果指定标签不存在，请检出 dispatch 引用；或者确保在启动工作流前标签已存在。
给 AI 代理的提示
在 `.github/workflows/publish.yml` 第 24 行：
**新的手动标签会阻止发布**
当 `workflow_dispatch` 运行提供尚未推送的新标签名称时，`actions/checkout` 会在 git-cliff 的后备逻辑运行之前失败，而 `build` 会因 `needs: changelog` 被阻止；因此，手动请求的发布既不会构建，也不会发布。
对于手动运行，如果指定标签不存在，请检出 dispatch 引用；或者确保在启动工作流前标签已存在。Original comment in English
🟡 Medium · New manual tags block publishing
When a workflow_dispatch run supplies a new tag name that has not been pushed yet, actions/checkout fails before the git-cliff fallback runs, and build is blocked by needs: changelog; the manually requested release therefore never builds or publishes.
For manual runs, check out the dispatch ref when the requested tag does not exist, or ensure the tag exists before starting the workflow.
Prompt for AI agents
In `.github/workflows/publish.yml` at line 24:
**New manual tags block publishing**
When a workflow_dispatch run supplies a new tag name that has not been pushed yet, `actions/checkout` fails before the git-cliff fallback runs, and `build` is blocked by `needs: changelog`; the manually requested release therefore never builds or publishes.
For manual runs, check out the dispatch ref when the requested tag does not exist, or ensure the tag exists before starting the workflow.|
|
||
| # 启用GitHub集成 | ||
| [git.github] | ||
| commits = true |
Contributor
There was a problem hiding this comment.
🟡 Medium · API 限流会导致变更日志丢失
当运行器发出的 GitHub API 请求超过未认证请求的速率限制时，GitHub 集成需要通过 API 获取提交元数据，但该作业只传递了 GITHUB_REPO，没有传递令牌。一旦未认证 API 请求受到限流，git-cliff 就会失败，而 continue-on-error 会导致发布仅使用静态后备内容，从而丢失变更摘要。
请将 ${{ secrets.GITHUB_TOKEN }} 作为 GITHUB_TOKEN 传递给 git-cliff 步骤。
另见 .github/workflows/publish.yml:52。
给 AI 代理的提示
在 `.github/cliff.toml` 第 116 行：
**API 限流会导致变更日志丢失**
当运行器发出的 GitHub API 请求超过未认证请求的速率限制时，GitHub 集成需要通过 API 获取提交元数据，但该作业只传递了 `GITHUB_REPO`，没有传递令牌。一旦未认证 API 请求受到限流，git-cliff 就会失败，而 `continue-on-error` 会导致发布仅使用静态后备内容，从而丢失变更摘要。
请将 `${{ secrets.GITHUB_TOKEN }}` 作为 `GITHUB_TOKEN` 传递给 git-cliff 步骤。
另见 `.github/workflows/publish.yml:52`。Original comment in English
🟡 Medium · API throttling drops the changelog
When gitHub API requests from the runner exceed the unauthenticated rate limit, the GitHub integration needs API access for commit metadata, but the job passes only GITHUB_REPO and no token. Once unauthenticated API requests are rate-limited, git-cliff fails and continue-on-error makes the release use only the static fallback, losing the change summary.
Pass ${{ secrets.GITHUB_TOKEN }} to the git-cliff step as GITHUB_TOKEN.
Also at .github/workflows/publish.yml:52.
Prompt for AI agents
In `.github/cliff.toml` at line 116:
**API throttling drops the changelog**
When gitHub API requests from the runner exceed the unauthenticated rate limit, the GitHub integration needs API access for commit metadata, but the job passes only `GITHUB_REPO` and no token. Once unauthenticated API requests are rate-limited, git-cliff fails and `continue-on-error` makes the release use only the static fallback, losing the change summary.
Pass `${{ secrets.GITHUB_TOKEN }}` to the git-cliff step as `GITHUB_TOKEN`.
Also at `.github/workflows/publish.yml:52`.| # 安装 | ||
|
|
||
| ```sh | ||
| pip install maa-mcp=={{ latest_version }} |
Contributor
There was a problem hiding this comment.
🟠 High · 安装命令使用了无效版本
当发布标签使用 v 前缀（符合工作流预期的正式发布标签格式）时，生成的页脚和后备内容都会保留此前缀，因此 pip 会查找 v1.3.0 这样的软件包版本，而不是实际发布的 1.3.0；按照任一安装命令操作的发布读者都无法安装该版本。
请在两个安装命令中，从根据标签生成的版本号中去掉开头的 v。
另见 .github/workflows/publish.yml:63。
给 AI 代理的提示
在 `.github/cliff.toml` 第 74 行：
**安装命令使用了无效版本**
当发布标签使用 `v` 前缀（符合工作流预期的正式发布标签格式）时，生成的页脚和后备内容都会保留此前缀，因此 pip 会查找 `v1.3.0` 这样的软件包版本，而不是实际发布的 `1.3.0`；按照任一安装命令操作的发布读者都无法安装该版本。
请在两个安装命令中，从根据标签生成的版本号中去掉开头的 `v`。
另见 `.github/workflows/publish.yml:63`。Original comment in English
🟠 High · Install command uses invalid version
When a release tag uses the v prefix, as the workflow’s formal-release tag pattern expects, the generated footer and fallback retain the v prefix, so pip looks for a package version such as v1.3.0 instead of the published 1.3.0; release readers following either installation command cannot install that version.
Strip the leading v from the tag-derived version in both installation commands.
Also at .github/workflows/publish.yml:63.
Prompt for AI agents
In `.github/cliff.toml` at line 74:
**Install command uses invalid version**
When a release tag uses the `v` prefix, as the workflow’s formal-release tag pattern expects, the generated footer and fallback retain the `v` prefix, so pip looks for a package version such as `v1.3.0` instead of the published `1.3.0`; release readers following either installation command cannot install that version.
Strip the leading `v` from the tag-derived version in both installation commands.
Also at `.github/workflows/publish.yml:63`.仓库已从 MistEO/MaaMCP 迁移到 MAA-AI/MaaMCP，旧地址靠 GitHub 重定向仍能 打开，但 PyPI 项目页展示的 Homepage / Repository 仍是旧名字。
KhazixW2
force-pushed
the
feat/release-changelog
branch
2 times, most recently
from
November 8, 2026 10:21
12af5d6 to
e964fe6
Compare
按 publish.yml 的真实参数验证 changelog job：检出目标 tag、用同样的 --current/--tag-pattern 组合，确认能生成含版本号的正文而不是退回静态说明。 正文改用 env 传递，避免多行内容插值进 shell 脚本。
KhazixW2
force-pushed
the
feat/release-changelog
branch
from
November 8, 2026 10:22
e964fe6 to
a2e6dcd
Compare
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
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.
CI 发版时 GitHub Release 正文只有一段静态安装说明，看不出这个版本改了什么。本 PR 接入 git-cliff，让每次发版自动按 conventional commits 汇总本次变更。
改动
.github/cliff.toml（新增）参考 MAAGC 的配置改写，按 commit 前缀分组：
featfixdocsperfrefactortest/style/chore/ci/removecommit.remote.username）remove分组（MaaMCP 有一条remove:commit）.github/workflows/publish.yml新增
changelogjob，build改为needs: changelog：actions/checkout带fetch-depth: 0（git-cliff 需要完整历史与 tag）与ref: ${{ inputs.tag || github.ref }}（检出版本对应的 tag）--current：只处理「属于当前 tag 的提交」，即本次要发布的那一版--tag-pattern "^v[0-9]+[.][0-9]+[.][0-9]+$"，把基线锁定在上一个正式版，这样 beta 期间的提交也会并入本次说明；预发布版不加该参数（否则输出为空）permissions:只读（contents: read+pull-requests: read）——git-cliff 拉 PR 元数据算贡献者统计需要pull-requests: readcontinue-on-error+ fallback 步骤），不阻塞发版顺带修掉旧写法的一个问题：原来
body:用 YAML 双引号标量，换行被折叠掉，Release 正文里的代码块挤成一行（sh pip install ...）。新的 fallback 用 heredoc 写到$GITHUB_OUTPUT，换行正常保留。pyproject.toml[project.urls]从已失效的MistEO/MaaMCP指向MAA-AI/MaaMCP（PyPI 项目元数据）。验证
actionlint 1.7.12对改后的publish.yml无告警git-cliff 2.14.2（action 默认版本）在真实仓库跑通，含detached HEAD 于 tag 的检出（与 CI 一致），v1.3.0 输出：预发布路径（不加
--tag-pattern）同样验证通过确认 action 的
run.sh会按 bash 规则拆分带引号的--tag-pattern正则，不会被截断在真实 GitHub Actions 里端到端跑通：用一个临时自检工作流复刻
publish.yml的 job（同样的permissions:、同样的--current/--tag-pattern参数），断言## <version>### 🐛 Bug修复），而不是 git-cliff 的内置默认格式该自检在 GitHub Actions 上通过后已删除（不属于本 PR 的最终改动）。
备注
本次同时把已发布的 v1.3.0 Release 正文补全了（原先是折叠成单行的静态说明）。
Original summary in English
Sourcery summary
Automatically generate rich GitHub Release notes while ensuring the publish workflow keeps working even if changelog generation fails.
New features:
Bug fixes:
Enhancements:
CI:
Tests:
Chores: