feat: improve release workflow with test gate, changelog script and smart summary#55
Conversation
…mart summary - Extract inline changelog shell into scripts/generate-changelog.sh - Add test job (go vet, go build, npm ci, npm run build) before release - Filter noise commits (chore/ci/release/bump/test/ignore) from notes - Add Full Changelog diff link at release notes bottom - Add path-based smart summary (detects changed modules automatically)
|
CodeAnt AI is reviewing your PR. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! 本次 PR 旨在优化项目的发布工作流，通过引入严格的构建前检查和自动化的 changelog 生成机制，提升发布过程的稳定性和文档质量。通过智能分析变更路径，系统能够自动归纳模块更新，减少人工编写 release notes 的负担。 Highlights
Ignored Files
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. Footnotes
|
codeant-ai
Bot
added
the
size:L
Up to standards ✅🟢 Issues
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a new shell script, generate-changelog.sh, which automates the generation of changelogs by categorizing git commits and identifying modified project modules. Feedback focused on adhering to the project's style guide regarding Chinese documentation for complex logic and improving the script's robustness by replacing echo with printf to safely handle special characters in commit messages and output.
| #!/usr/bin/env bash | ||
| # 用法: ./scripts/generate-changelog.sh <current_tag> [repo_url] | ||
| # 输出 GITHUB_OUTPUT 多行格式: body<<EOF ... EOF | ||
| set -euo pipefail |
There was a problem hiding this comment.
根据项目代码审查规范第 89 条和第 90 条，复杂逻辑应有中文注释，且函数应有文档注释。虽然脚本整体逻辑清晰，但建议在脚本开头添加功能描述，并为 touches 函数及后续的 Commit 分类循环、GitHub Output 格式输出等关键逻辑块添加简要的中文说明，以提高代码的可维护性。
References
- 复杂逻辑必须有中文注释说明；公共函数必须有文档注释 (link)
| touches() { | ||
| echo "$CHANGED_FILES" | grep -qE "$1" 2>/dev/null | ||
| } |
There was a problem hiding this comment.
在处理可能包含特殊字符（如以 - 开头）的变量时，使用 printf 比 echo 更健壮。此外，grep -q 已经静默输出，通常不需要重定向 2>/dev/null。
| touches() { | |
| echo "$CHANGED_FILES" | grep -qE "$1" 2>/dev/null | |
| } | |
| touches() { | |
| printf "%s\n" "$CHANGED_FILES" | grep -qE "$1" | |
| } |
| [ -z "$line" ] && continue | ||
| [[ $line =~ $NOISE_REGEX ]] && continue | ||
|
|
||
| clean_line=$(echo "$line" | sed 's/\\/\\\\/g; s/`/\\`/g') |
There was a problem hiding this comment.
建议使用 printf 代替 echo 以避免 commit message 内容被误认为 echo 选项。另外，如果后续输出不再使用 echo -e，则无需在此处对反斜杠进行双重转义，仅保留对 Markdown 特殊字符（如反引号）的处理即可。
| clean_line=$(echo "$line" | sed 's/\\/\\\\/g; s/`/\\`/g') | |
| clean_line=$(printf "%s" "$line" | sed 's/`/\\`/g') |
|
|
||
| { | ||
| echo "body<<EOF" | ||
| echo -e "$BODY" |
There was a problem hiding this comment.
建议使用 printf "%s\n" 代替 echo -e。echo -e 会解析变量中的转义序列（如 \n, \t），可能导致 commit message 中的原始字符被意外转换。由于 $BODY 变量已包含所需的换行符，直接输出即可保证内容的原始性。
| echo -e "$BODY" | |
| printf "%s\n" "$BODY" |
![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
| if [[ $line =~ ^feat ]]; then | ||
| FEATS="$FEATS | ||
| - ${clean_line#feat: }" |
There was a problem hiding this comment.
Suggestion: The matcher classifies any subject starting with feat (including feat(scope): ...) but the string trim only removes the exact feat: prefix, so scoped conventional commits are rendered with their raw prefix instead of clean titles. This produces malformed/unclean release notes. Strip commit type using a pattern that handles scoped and bang variants consistently (e.g., feat(scope)!:). [logic error]
Severity Level: Major ⚠️
- ⚠️ Features section shows noisy feat(scope): prefixes.
- ⚠️ Generated release notes look inconsistent across commit styles.Steps of Reproduction ✅
1. A tag push triggers the release workflow `.github/workflows/release.yml`, which runs
the changelog script in the "生成 Release Notes" step at lines 16–19 with `CURRENT_TAG` set
to the tag name and a repository URL.
2. Between `PREV_TAG` and `CURRENT_TAG`, assume there is at least one commit following the
Conventional Commits style with a scope, for example `feat(desktop): Improve navbar`,
which is realistic given the script's use of type prefixes (`feat`, `fix`, `docs`, etc.)
and scoped paths (desktop/backend) in `scripts/generate-changelog.sh`.
3. At `scripts/generate-changelog.sh:73`, `LOGS` is populated by `git log
"$PREV_TAG".."$CURRENT_TAG" --pretty=format:"%s" --no-merges`, so the literal subject
`feat(desktop): Improve navbar` is included. The processing loop at lines 80–102 reads
each line into `line`, skips noise via `NOISE_REGEX` at line 72 (which does not filter
`feat(...)`), and builds `clean_line` at line 84.
4. For this feature commit, the condition `if [[ $line =~ ^feat ]]; then` at line 86
evaluates true (it matches `feat(desktop):`), but the string trimming `${clean_line#feat:
}` at line 88 only removes the literal `feat: ` prefix, not `feat(scope): `. As a result,
the generated Features section at lines 113–116 contains an entry like `- feat(desktop):
Improve navbar` instead of a normalized `- Improve navbar`, while unscoped `feat: Add X`
entries are rendered cleanly. This creates inconsistent and noisy feature titles whenever
scoped `feat(scope):` commits are present in the release range.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** scripts/generate-changelog.sh
**Line:** 86:88
**Comment:**
*Logic Error: The matcher classifies any subject starting with `feat` (including `feat(scope): ...`) but the string trim only removes the exact `feat: ` prefix, so scoped conventional commits are rendered with their raw prefix instead of clean titles. This produces malformed/unclean release notes. Strip commit type using a pattern that handles scoped and bang variants consistently (e.g., `feat(scope)!:`).
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
|
CodeAnt AI finished reviewing your PR. |
- Replace echo with printf for robustness with special characters - Fix scoped conventional commit prefix stripping (feat(scope):) - Use POSIX [[:space:]] instead of \s for BSD sed compatibility - Replace echo -e with printf for safe output
…mart summary (#55) * feat: improve release workflow with test gate, changelog script and smart summary - Extract inline changelog shell into scripts/generate-changelog.sh - Add test job (go vet, go build, npm ci, npm run build) before release - Filter noise commits (chore/ci/release/bump/test/ignore) from notes - Add Full Changelog diff link at release notes bottom - Add path-based smart summary (detects changed modules automatically) * fix: address code review feedback on changelog script - Replace echo with printf for robustness with special characters - Fix scoped conventional commit prefix stripping (feat(scope):) - Use POSIX [[:space:]] instead of \s for BSD sed compatibility - Replace echo -e with printf for safe output
|
CodeAnt AI is running the review. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
codeant-ai
Bot
added
size:L
Sequence DiagramThis PR updates the release workflow to gate builds on backend/frontend checks and generates structured release notes via a shared changelog script with module summaries and a full changelog link. sequenceDiagram
participant Developer
participant Actions
participant TestJob
participant BuildRelease
participant ChangelogScript
participant GitHubRelease
Developer->>Actions: Push tag
Actions->>TestJob: Run pre-release checks (go vet/build, npm ci/build)
TestJob-->>Actions: Checks passed
Actions->>BuildRelease: Start build and release job
BuildRelease->>ChangelogScript: Generate changelog for current tag
ChangelogScript-->>BuildRelease: Return grouped notes and module summary
BuildRelease->>GitHubRelease: Publish artifacts with generated notes
GitHubRelease-->>Developer: Release with clean notes and full changelog link
Generated by CodeAnt AI |
| PREV_TAG=$(git describe --tags --abbrev=0 "$CURRENT_TAG^" 2>/dev/null || git rev-list --max-parents=0 HEAD) | ||
| echo "Previous tag: $PREV_TAG" >&2 | ||
|
|
||
| CHANGED_FILES=$(git diff --name-only "$PREV_TAG".."$CURRENT_TAG" 2>/dev/null || true) |
There was a problem hiding this comment.
Suggestion: git diff/git log failures are explicitly swallowed with || true, which makes the workflow continue and publish fallback text even when tags/history are invalid or unavailable. This hides real release-note generation failures and can produce incorrect release content; remove the silent fallback and fail the step when git range queries fail. [logic error]
Severity Level: Major ⚠️
- ⚠️ Local changelog runs hide git history resolution failures.
- ⚠️ Release workflows may publish generic notes after git errors.Steps of Reproduction ✅
1. From any non-git directory (for example `/tmp`), copy `scripts/generate-changelog.sh`
from this repo and run `bash generate-changelog.sh v0.1.0 https://github.com/org/repo` as
suggested by the usage comment at `scripts/generate-changelog.sh:2-3`.
2. Because the current working directory is not a git repository, the `git diff
--name-only "$PREV_TAG".."$CURRENT_TAG"` command at `scripts/generate-changelog.sh:12`
fails with "fatal: not a git repository"; however, the `2>/dev/null || true` suffix forces
the entire command substitution to succeed and silently assigns an empty string to
`CHANGED_FILES`.
3. Later, the `git log "$PREV_TAG".."$CURRENT_TAG"` call at
`scripts/generate-changelog.sh:74` also fails in the non-git directory, but again
`2>/dev/null || true` suppresses the error and leaves `LOGS` empty, so the loop at
`scripts/generate-changelog.sh:81-106` never populates `FEATS`, `FIXES`, `DOCS`, or
`OTHERS`.
4. With both `CHANGED_FILES` and `LOGS` empty, the script falls back to the generic
message at `scripts/generate-changelog.sh:134` and still prints a `body<<EOF ... EOF`
block at `scripts/generate-changelog.sh:142-145` with exit status 0, so callers (including
workflows like `.github/workflows/release.yml:125-129`) cannot detect that git history
resolution failed and receive misleading "successful" release notes.Fix in Cursor | Fix in VSCode Claude
(Use Cmd/Ctrl + Click for best experience)
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** scripts/generate-changelog.sh
**Line:** 12:12
**Comment:**
*Logic Error: `git diff`/`git log` failures are explicitly swallowed with `|| true`, which makes the workflow continue and publish fallback text even when tags/history are invalid or unavailable. This hides real release-note generation failures and can produce incorrect release content; remove the silent fallback and fail the step when git range queries fail.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
Once fix is implemented, also check other comments on the same PR, and ask user if the user wants to fix the rest of the comments as well. if said yes, then fetch all the comments validate the correctness and implement a minimal fix
|
CodeAnt AI finished running the review. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
1 participant
User description
Summary
go vet、go build、npm ci、npm run build，防止发布坏包scripts/generate-changelog.sh，逻辑更清晰可维护chore:,ci:,release:,bump:,test:,ignore:前缀不再出现在 release notesTest plan
bash -n scripts/generate-changelog.sh语法检查通过CodeAnt-AI Description
Add a release gate and cleaner release notes
What Changed
Impact
✅ Fewer broken releases✅ Clearer release notes✅ Easier upgrade review🔄 Retrigger CodeAnt AI Review
Details
💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.