ci(release): add release-please for automated releases#6
Conversation
- Add release-please-config.json with simple release type - Add .release-please-manifest.json starting at v0.0.1 - Add GitHub Actions workflow for release automation - Update heartbeat.lua with x-release-please-version annotation 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
Summary of ChangesHello @AnnatarHe, 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! This pull request integrates "release-please" to establish an automated release workflow for the project. By leveraging conventional commits, this setup will automatically manage version bumps, generate comprehensive changelogs, and create GitHub releases, significantly streamlining the release process and ensuring consistency. 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. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
Codecov Report✅ All modified and coverable lines are covered by tests. 🚀 New features to boost your workflow:
|
Code Review: Release Automation SetupOverall, this is a well-structured PR that adds automated release management using release-please. The implementation is clean and follows good practices. Here are my findings: ✅ Strengths
🔍 Issues & Recommendations1. Version Downgrade (Breaking Change)
2. Missing Version Sources
3. Missing Changelog Section
{ "type": "ci", "section": "CI/CD" }4. Workflow Trigger Consideration
5. Security: Token Permissions
📋 Testing RecommendationsSince this is CI/CD infrastructure (not testable via unit tests), verify:
🏗️ Architecture & Code Quality
🎯 Minor Nits
📝 Suggested Follow-ups (not blocking)
Final VerdictApprove with Minor Suggestions ✅ The implementation is solid and production-ready. The only blocking concern is verifying whether the version downgrade from Review performed by Claude Code following CLAUDE.md conventions |
![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 sets up release-please for automated releases by adding the necessary configuration files. The changes correctly configure a simple release type, set the initial version, and mark the version string in the Lua code for updates.
However, there is a critical omission: the GitHub Action workflow file (.github/workflows/release.yml), which is mentioned in the PR description, is missing from the changes. Without this file, release-please will not run, and no automated releases will be created. Please add the workflow file to this pull request.
I've also added a couple of suggestions to the release-please-config.json to make the configuration more robust and the generated changelogs more comprehensive.
| { "type": "feat", "section": "Features" }, | ||
| { "type": "fix", "section": "Bug Fixes" }, | ||
| { "type": "perf", "section": "Performance Improvements" }, | ||
| { "type": "refactor", "section": "Code Refactoring" }, | ||
| { "type": "docs", "section": "Documentation" }, | ||
| { "type": "test", "section": "Tests" }, | ||
| { "type": "chore", "section": "Miscellaneous" } |
There was a problem hiding this comment.
The changelog-sections list is missing some common conventional commit types like build, ci, style, and revert. Including them will create a more comprehensive and organized changelog. The current PR, for example, has a ci type and it would be good to have it reflected in its own section in the changelog.
{ "type": "feat", "section": "Features" },
{ "type": "fix", "section": "Bug Fixes" },
{ "type": "perf", "section": "Performance Improvements" },
{ "type": "refactor", "section": "Code Refactoring" },
{ "type": "revert", "section": "Reverts" },
{ "type": "docs", "section": "Documentation" },
{ "type": "style", "section": "Styles" },
{ "type": "test", "section": "Tests" },
{ "type": "build", "section": "Build System" },
{ "type": "ci", "section": "Continuous Integration" },
{ "type": "chore", "section": "Miscellaneous" }| "extra-files": [ | ||
| "lua/shelltime/heartbeat.lua" | ||
| ] |
There was a problem hiding this comment.
While using just the file path in extra-files works with the x-release-please-version comment, it's more robust and self-documenting to explicitly define how the version string should be updated. Using a regular expression makes the configuration clearer and less prone to accidental changes.
"extra-files": [
{
"type": "re",
"path": "lua/shelltime/heartbeat.lua",
"pattern": "local PLUGIN_VERSION = '(?<version>.*)' -- x-release-please-version"
}
]1 participant
Summary
simplerelease type for Lua/Neovim plugin0.0.1heartbeat.luafor automatic version updatesChanges
.github/workflows/release.yml- Release workflow triggered on push to mainrelease-please-config.json- Configuration with changelog sections.release-please-manifest.json- Version tracking manifestlua/shelltime/heartbeat.lua- Addedx-release-please-versionannotationHow it works
main🤖 Generated with Claude Code