Conversation
📝 WalkthroughWalkthroughThis PR adds changelog and release automation: new release-drafter config, workflows to draft releases and update CHANGELOG.md, updates to PR template and CONTRIBUTING.md with changelog label guidelines (CONTRIBUTING.md contains duplicated section), and a new CHANGELOG.md plus README links and development notes. Changes
Sequence Diagram(s)sequenceDiagram
actor User
participant GH as GitHub Actions
participant RD as Release Drafter
participant CU as Changelog Updater
participant Repo as Repository
User->>GH: Trigger "Tag and Release" workflow (manual)
GH->>Repo: Create tag (step outputs new_tag)
GH->>RD: Publish release using new_tag (release-drafter config)
RD->>Repo: Update release draft (categories from labels)
Repo->>GH: release published event
GH->>CU: Run changelog updater with release notes
CU->>Repo: Commit updated CHANGELOG.md and open PR (label: changelog:skip)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 📜 Recent review detailsConfiguration used: defaults Review profile: CHILL Plan: Pro 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @.github/workflows/update-changelog.yml:
- Around line 26-36: The workflow step using peter-evans/create-pull-request@v6
sets labels with an unquoted colon-containing string which can break YAML
parsing; update the Create Pull Request step by changing the labels field from
labels: changelog:skip to labels: "changelog:skip" (or use a quoted list like
labels: "changelog:skip" or labels: "changelog:skip,other") so the labels value
is quoted and parsed correctly.
In @CHANGELOG.md:
- Around line 1-15: The [Unreleased] comparison link currently points to a
non-existent tag "v0.0.51"; update the reference in the CHANGELOG's
"[Unreleased]" link target to a valid release tag (for example replace "v0.0.51"
with the actual latest released tag like "v0.0.50" or the correct tag used in
your repo) or remove the URL entirely if no valid comparison point exists so the
link no longer resolves to a 404.
🧹 Nitpick comments (6)
CHANGELOG.md (1)
12-12: Optional: Consider concise wording for line 12.The phrase "prior to automated changelog generation" could be shortened to "before automated changelog generation" for better conciseness, though the current wording is acceptable.
.github/workflows/release-drafter.yml (2)
10-19: Remove redundant workflow-level permissions.The job-level permissions (lines 17-19) override the workflow-level permissions (lines 10-12), making the top-level declaration redundant.
♻️ Simplify by keeping only job-level permissions
-permissions: - contents: read - pull-requests: write - jobs: update_release_draft: runs-on: ubuntu-latest permissions: contents: write pull-requests: write
21-21: Consider pinning to a specific release or commit SHA.Using
@v6references a mutable major version tag. GitHub security guidance recommends pinning to a full commit SHA for maximum security, or to a specific release tag (likev6.1.0) for a balance between stability and convenience. If using the major version tag, keep it updated using Dependabot or similar automation..github/release-drafter.yml (2)
10-28: Consider adding a "Deprecated" category.The categories follow the Keep a Changelog standard but are missing the "Deprecated" section, which is useful for tracking features marked for removal in future versions.
♻️ Add Deprecated category
- title: 'Fixed' labels: - 'changelog:fixed' + - title: 'Deprecated' + labels: + - 'changelog:deprecated' - title: 'Removed' labels: - 'changelog:removed'Don't forget to document the new
changelog:deprecatedlabel in the PR template if you add this category.
46-66: Consider adding autolabeler patterns for security and removed changes.The autolabeler configuration covers most common change types but is missing patterns for security and removed changes, which are defined in the categories section.
♻️ Add patterns for security and removed
- label: 'changelog:skip' title: - '/^chore/i' - '/^ci/i' - '/^docs/i' + - label: 'changelog:security' + title: + - '/security/i' + - '/vulnerability/i' + - '/cve/i' + - label: 'changelog:removed' + title: + - '/remove/i' + - '/delete/i'.github/workflows/create-tag-and-exit.yml (1)
51-52: Remove unnecessary checkout step.The
release-drafteraction withpublish: trueoperates entirely through the GitHub API and does not require a repository checkout. The action reads its configuration file via the API and needs only theGITHUB_TOKENwith write permissions, both of which are already configured. This step can be safely removed.
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
.github/CONTRIBUTING.md.github/PULL_REQUEST_TEMPLATE.md.github/release-drafter.yml.github/workflows/create-tag-and-exit.yml.github/workflows/release-drafter.yml.github/workflows/update-changelog.ymlCHANGELOG.mdREADME.md
🧰 Additional context used
🪛 GitHub Actions: Release Drafter
.github/release-drafter.yml
[error] 1-1: Configuration file .github/release-drafter.yml is not found. The configuration file must reside in your default branch.
🪛 LanguageTool
CHANGELOG.md
[style] ~12-~12: ‘prior to’ might be wordy. Consider a shorter alternative.
Context: ...] ## Historical Releases For releases prior to automated changelog generation, please ...
(EN_WORDINESS_PREMIUM_PRIOR_TO)
README.md
[uncategorized] ~343-~343: The official name of this software platform is spelled with a capital “H”.
Context: ... Please see our Contributing Guidelines for more information. ...
(GITHUB)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Build Docker Image
- GitHub Check: Build Docker Image
- GitHub Check: Analyze (go)
🔇 Additional comments (16)
README.md (1)
343-345: Excellent integration of contribution and changelog references.The addition of links to Contributing Guidelines and CHANGELOG improves discoverability and aligns with the new changelog infrastructure. The paths are correct and integrate naturally with the existing documentation flow.
.github/CONTRIBUTING.md (1)
66-100: Changelog guidelines are comprehensive and properly implemented.All label definitions and automatic labeling rules documented in CONTRIBUTING.md are correctly configured in
.github/release-drafter.yml:
- All seven changelog labels (
changelog:added,changelog:changed,changelog:fixed,changelog:removed,changelog:security,changelog:skip,changelog:breaking) are defined in the release-drafter configuration- Automatic labeling rules match the documented behavior exactly:
- PR titles with "fix"/"bug" →
changelog:fixed- PR titles with "add"/"feat"/"new" →
changelog:added- PR titles with "update"/"improve"/"enhance" →
changelog:changed- PR titles starting with "chore"/"ci"/"docs" →
changelog:skip- The
changelog:skiplabel is properly configured as an exclude-label and applied to auto-generated PRsThe guidelines are production-ready and align with the actual release automation implementation.
.github/workflows/release-drafter.yml (1)
3-8: LGTM!The trigger configuration is appropriate for automated release drafting, with PR events covering label changes that feed into the release categorization.
.github/workflows/create-tag-and-exit.yml (4)
1-1: LGTM!The workflow name accurately reflects the expanded functionality that now includes both tagging and release publishing.
16-17: LGTM!The output exposure is correctly configured to pass the created tag to the downstream publish_release job.
25-41: LGTM!The step ID and output assignment are correctly configured using the modern
$GITHUB_OUTPUTsyntax.
54-61: LGTM with version pinning consideration.The release publication configuration correctly uses the tag output from the previous job and will publish the draft release. Consider the version pinning recommendation made for the release-drafter.yml workflow.
.github/PULL_REQUEST_TEMPLATE.md (1)
35-44: LGTM!The changelog label mappings are clear and consistent with the release-drafter configuration. The explicit guidance will help contributors properly categorize their changes.
.github/workflows/update-changelog.yml (3)
1-9: LGTM!The trigger and permissions are correctly configured for automated changelog updates following release publication.
15-18: LGTM!Full history checkout is appropriate for changelog operations that may need to reference previous releases and commits.
20-24: No changes needed.The action configuration is correct. Version pinning to
@v1follows standard SemVer practice and is the recommended approach used in the action's own documentation. The action is designed for "Keep a Changelog" format and is flexible enough to work with your CHANGELOG.md. The inputs (latest-version and release-notes) are standard and properly sourced from the release event.Likely an incorrect or invalid review comment.
.github/release-drafter.yml (5)
1-2: LGTM!The version templates follow semantic versioning conventions with the 'v' prefix.
3-8: LGTM!The release notes template follows standard conventions and includes all necessary sections for clear release communication.
30-31: LGTM!The change entry format is clear and includes all relevant information with appropriate markdown escaping.
33-44: LGTM!The version resolution logic correctly follows semantic versioning principles with appropriate label mappings for major, minor, and patch increments.
1-66: Pipeline failure is expected before merge.The noted pipeline failure indicating the configuration file is not found is expected since this file is being added in this PR. The error will resolve automatically once the PR is merged to the main branch.
| # Changelog | ||
|
|
||
| All notable changes to ZXporter will be documented in this file. | ||
|
|
||
| The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/), | ||
| and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). | ||
|
|
||
| ## [Unreleased] | ||
|
|
||
| ## Historical Releases | ||
|
|
||
| For releases prior to automated changelog generation, please see the | ||
| [GitHub Releases](https://github.com/devzero-inc/zxporter/releases) page. | ||
|
|
||
| [Unreleased]: https://github.com/devzero-inc/zxporter/compare/v0.0.51...HEAD |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
git tag -l | grep -E '^v0\.0\.51$'Repository: devzero-inc/zxporter
Length of output: 46
Replace the non-existent v0.0.51 tag reference with a valid version tag.
The comparison URL on line 15 references v0.0.51, but this tag does not exist in the repository. The link will be invalid, breaking documentation for users. Update the URL to reference an actual tagged release or remove the link until a valid comparison point is available.
🧰 Tools
🪛 LanguageTool
[style] ~12-~12: ‘prior to’ might be wordy. Consider a shorter alternative.
Context: ...] ## Historical Releases For releases prior to automated changelog generation, please ...
(EN_WORDINESS_PREMIUM_PRIOR_TO)
🤖 Prompt for AI Agents
In @CHANGELOG.md around lines 1 - 15, The [Unreleased] comparison link currently
points to a non-existent tag "v0.0.51"; update the reference in the CHANGELOG's
"[Unreleased]" link target to a valid release tag (for example replace "v0.0.51"
with the actual latest released tag like "v0.0.50" or the correct tag used in
your repo) or remove the URL entirely if no valid comparison point exists so the
link no longer resolves to a 404.
1 participant
[Title]
📚 Description of Changes
Provide an overview of your changes and why they’re needed. Link to any related issues (e.g., "Fixes #123"). If your PR fixes a bug, resolves a feature request, or updates documentation, please explain how.
What Changed:
(Describe the modifications, additions, or removals.)
Why This Change:
(Explain the problem this PR addresses or the improvement it provides.)
Affected Components:
(Which component does this change affect? - put x for all components)
Compose
K8s
Other (please specify)
❓ Motivation and Context
Why is this change required? What problem does it solve?
Context:
(Provide background information or link to related discussions/issues.)
Relevant Tasks/Issues:
(e.g., Fixes: #GitHub Issue)
🔍 Types of Changes
Indicate which type of changes your code introduces (check all that apply):
🔬 QA / Verification Steps
Describe the steps a reviewer should take to verify your changes:
make testto verify all tests pass.")make create-kind && make deploy.")✅ Global Checklist
Please check all boxes that apply:
Summary by CodeRabbit
Documentation
Chores
✏️ Tip: You can customize this high-level summary in your review settings.