Move logic for release notes generation from Python script to Jinja template (release CI) #44
Conversation
WalkthroughThe changes involve updates to the logic for processing release notes in the Changes
Possibly related PRs
Suggested labels
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
Outside diff range and nitpick comments (6)
cliff.toml (4)
20-25: LGTM! Consider using a constant for "Unreleased".The introduction of
init_commitandthis_versionvariables, along with the logic to setthis_versionbased on the inputversion, looks good. It provides a clear way to handle both released and unreleased versions in the changelog.Consider defining "Unreleased" as a constant at the top of the file, as it's used multiple times. This would make future updates easier and ensure consistency. For example:
{% set UNRELEASED = "Unreleased" %} # ... other code ... {% set this_version = UNRELEASED %} # ... use UNRELEASED instead of "Unreleased" in other places
47-54: LGTM! Consider adding comments for clarity.The logic for determining
first_commitandlast_commitis well-structured and covers all necessary cases. It properly handles scenarios with and without previous versions.Consider adding brief comments to explain the logic, especially for the
first_commitfallback toinit_commit. This would enhance maintainability. For example:{% set first_commit = previous.version %} {% set last_commit = "HEAD" %} {% if version %} {% set last_commit = version %} {% if not previous.version %} {# If this is the first versioned release, use the initial commit #} {% set first_commit = init_commit %} {% endif %} {% endif %}
55-61: LGTM! Consider consistent formatting for commit hashes.The addition of comparison and full commit diff links enhances the changelog's usefulness. The conditional logic for handling the initial commit in the full diff link is well-thought-out.
For consistency, consider using the same truncation for both
init_commitandfirst_commitin the full diff link. Currently, onlyinit_commitis truncated. You could apply the same truncation tofirst_commit:Full commit diff: [`{% if previous.version -%} {{ first_commit | truncate(length=7, end="") }} {%- else -%} {{ init_commit | truncate(length=7, end="") }} {%- endif %}...{{ last_commit }}`][{{ this_version }}]This ensures that regardless of which commit is used, it's displayed in the same format.
Line range hint
1-150: Overall, these changes significantly enhance the changelog generation process.The modifications to
cliff.tomlalign well with the PR objective of moving logic from a Python script to the Jinja template. Key improvements include:
- Introduction of variables for better version handling (
init_commit,this_version,first_commit,last_commit).- Enhanced logic for determining version ranges in the changelog.
- Addition of comparison and full commit diff links for better traceability.
These changes make the changelog more informative and flexible, especially in handling different release scenarios (initial release, subsequent releases, unreleased changes). The use of Jinja templating allows for more dynamic content generation directly in the configuration file.
To further improve maintainability and consistency:
- Consider extracting commonly used strings (like "Unreleased") into constants at the top of the file.
- Add comments to explain complex logic, especially around version comparisons and link generation.
- Ensure consistent formatting throughout the template, particularly for commit hash displays.
These enhancements will make the configuration more robust and easier to maintain as the project evolves.
CHANGELOG.md (2)
13-13: LGTM! Consider adding dates to unreleased changes.The new entry for automation of version bump and release workflows is well-documented, including attribution and a link to the pull request. The addition of a full commit diff link for unreleased changes is an excellent practice for transparency.
Consider adding a date or date range for the unreleased changes to give readers a sense of how recent these changes are. For example:
## [Unreleased] - 2024-09-21 to presentAlso applies to: 27-30
135-136: LGTM! Comprehensive first release candidate section.The new section for the first release candidate 2.0.0-rc1 is well-structured and highly informative. It maintains consistency with other sections while providing more detailed information about the changes, which is appropriate for the first release candidate. The inclusion of the release date, comparison link, and full commit diff link continues to provide excellent traceability.
Consider adding a brief summary or highlights of the most significant changes in this first release candidate at the beginning of the section. This can help readers quickly grasp the major updates without having to go through the entire list of changes.
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (3)
- .github/workflows/bump_version.py (0 hunks)
- CHANGELOG.md (5 hunks)
- cliff.toml (3 hunks)
Files not reviewed due to no reviewable changes (1)
- .github/workflows/bump_version.py
Additional comments not posted (6)
cliff.toml (2)
45-46: LGTM! Improved readability.The addition of empty lines after the commit grouping loop enhances the readability of the generated changelog.
80-80: Clarify the reason for commenting out the output configuration.The
outputconfiguration has been commented out. While this will allow git-cliff to use its default output behavior, it's unclear why this change was made.Could you please clarify the reasoning behind this change? Is the output being handled differently in the CI process now? If so, it might be helpful to add a comment explaining the new approach:
# output = "CHANGELOG.md" # Output is now handled in the CI pipelineThis would help future maintainers understand the intentional omission of this configuration.
CHANGELOG.md (4)
41-44: LGTM! Well-structured release candidate section.The new section for release candidate 2.0.0-rc4 is well-structured and informative. The inclusion of the release date, comparison link, and full commit diff link greatly enhances the traceability of changes between versions.
52-55: LGTM! Consistent structure maintained.The new section for release candidate 2.0.0-rc3 maintains the consistent structure established in the previous section. The inclusion of the release date, comparison link, and full commit diff link continues to provide excellent traceability between versions.
73-76: LGTM! Consistent structure maintained across release candidates.The new section for release candidate 2.0.0-rc2 continues to maintain the consistent structure established in the previous sections. The inclusion of the release date, comparison link, and full commit diff link provides excellent traceability between versions.
Line range hint
1-136: Excellent improvements to the changelog structure and content!The changes made to the CHANGELOG.md file significantly enhance its usefulness and readability:
- Consistent structure across all sections (Unreleased and release candidates).
- Enhanced traceability with comparison links and full commit diff links for each version.
- Clear adherence to the Keep a Changelog format and Semantic Versioning.
- Detailed categorization of changes (Added, Fixed, Dependency updates, etc.) within each section.
These improvements make it much easier for users and contributors to understand the project's evolution and find specific changes between versions.
There was a problem hiding this comment.
Actionable comments posted: 0
Outside diff range and nitpick comments (3)
CHANGELOG.md (3)
9-31: LGTM! Consider adding more details to some entries.The new "Unreleased" section follows the Keep a Changelog format and provides a clear overview of recent changes. The addition of the "Dependency updates" section is a good practice for tracking dependencies.
Consider adding more details to some entries, such as the one in line 30:
- Move logic from py script to jinja template (release CI) in [`bc05419`](https://github.com/cpp-linter/cpp_linter_rs/commit/bc05419920e15704352d344a4fa7da67824cc776) + Move logic for release notes generation from Python script to Jinja template (release CI) in [`bc05419`](https://github.com/cpp-linter/cpp_linter_rs/commit/bc05419920e15704352d344a4fa7da67824cc776)This provides more context about the specific logic that was moved.
Tools
LanguageTool
[grammar] ~25-~25: There seems to be a noun/verb agreement error. Did you mean “follows” or “followed”?
Context: ...8 --> 📝 Documentation - Release trial follow up by @2bndy5 in [#41](https://github.c...(SINGULAR_NOUN_VERB_AGREEMENT)
Line range hint
32-81: LGTM! Consider standardizing the format of commit messages.The new sections for release candidates 2.0.0-rc4, 2.0.0-rc3, and 2.0.0-rc2 are well-structured and provide clear information about the changes. The inclusion of full commit diff links improves traceability.
For consistency, consider standardizing the format of commit messages. For example, in the 2.0.0-rc3 section:
- [node] add life cycle script prepublishOnly by @2bndy5 in [`55650ea`](https://github.com/cpp-linter/cpp_linter_rs/commit/55650ea96aac628023acb120525d674bcf17a529) + Add life cycle script prepublishOnly for node by @2bndy5 in [`55650ea`](https://github.com/cpp-linter/cpp_linter_rs/commit/55650ea96aac628023acb120525d674bcf17a529)This format aligns better with the other entries and provides clearer information.
Line range hint
82-139: LGTM! Consider adding more context to some entries.The 2.0.0-rc1 section provides a comprehensive and well-categorized list of changes for the first release candidate. This level of detail is excellent for tracking the project's progress.
To further improve clarity, consider adding more context to some entries. For example:
- Init commit by @2bndy5 in [`2e25fec`](https://github.com/cpp-linter/cpp_linter_rs/commit/2e25fec0a447df24d0bcc1b80f6624040bab755e) + Initial commit: Project setup and basic structure by @2bndy5 in [`2e25fec`](https://github.com/cpp-linter/cpp_linter_rs/commit/2e25fec0a447df24d0bcc1b80f6624040bab755e)This provides more information about what the initial commit included.
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files selected for processing (2)
- CHANGELOG.md (4 hunks)
- cliff.toml (3 hunks)
Files skipped from review as they are similar to previous changes (1)
- cliff.toml
Additional context used
LanguageTool
CHANGELOG.md
[grammar] ~25-~25: There seems to be a noun/verb agreement error. Did you mean “follows” or “followed”?
Context: ...8 --> 📝 Documentation - Release trial follow up by @2bndy5 in [#41](https://github.c...(SINGULAR_NOUN_VERB_AGREEMENT)
Additional comments not posted (2)
CHANGELOG.md (2)
140-141: LGTM! Excellent addition of full commit diff links.The inclusion of full commit diff links for each version significantly enhances the changelog's traceability. This allows developers to easily view all changes between versions.
25-25: Note on grammar: Current phrasing is acceptable in this context.The static analysis tool flagged a potential noun/verb agreement issue in the phrase "Release trial follow up". However, in the context of a changelog entry, this concise format is acceptable and commonly used. It effectively conveys the nature of the change without requiring strict grammatical structure.
If you prefer to adhere to more formal grammar, you could consider:
- Release trial follow up by @2bndy5 in [#41](https://github.com/cpp-linter/cpp_linter_rs/pull/41) + Release trial follow-up by @2bndy5 in [#41](https://github.com/cpp-linter/cpp_linter_rs/pull/41)This adds a hyphen to create a compound modifier, which is grammatically correct. However, the current form is also acceptable in this context.
Tools
LanguageTool
[grammar] ~25-~25: There seems to be a noun/verb agreement error. Did you mean “follows” or “followed”?
Context: ...8 --> 📝 Documentation - Release trial follow up by @2bndy5 in [#41](https://github.c...(SINGULAR_NOUN_VERB_AGREEMENT)
2bndy5
changed the title
Summary by CodeRabbit
New Features
Bug Fixes
Documentation