chore: prepare v1.12.0 release with streamlined release workflow#172
Merged
Conversation
Contributor
Reviewer's GuidePrepares the v1.12.0 release by bumping the gem version, introducing a significantly more detailed changelog and user-facing upgrade documentation, and expanding the GitHub Actions release workflow into a one-click, version-verified pipeline that runs tests, builds, tags, and publishes the gem. Sequence diagram for the new one-click release workflowsequenceDiagram
actor Maintainer
participant GitHub_UI
participant GitHub_Actions as GitHub_Actions_release_yml
participant Repo as GitHub_Repository
participant RubyGems as RubyGems_org
Maintainer->>GitHub_UI: Run workflow release.yml with version input
GitHub_UI->>GitHub_Actions: workflow_dispatch event(version)
GitHub_Actions->>Repo: actions/checkout checks out repository
GitHub_Actions->>GitHub_Actions: Set up Ruby with ruby/setup-ruby
GitHub_Actions->>GitHub_Actions: Verify version
GitHub_Actions->>GitHub_Actions: Read GEM_VERSION from workflow input
GitHub_Actions->>GitHub_Actions: Read RUBY_VERSION from lib capybara screenshot diff version
GitHub_Actions-->>GitHub_Actions: Compare GEM_VERSION and RUBY_VERSION
alt Version mismatch
GitHub_Actions-->>Maintainer: Fail workflow with version mismatch
else Version matches
GitHub_Actions->>GitHub_Actions: bundle exec rake test
GitHub_Actions->>GitHub_Actions: bundle exec rake build
GitHub_Actions->>Repo: Configure git user and create tag v<version>
GitHub_Actions->>Repo: Push tag v<version> to origin
GitHub_Actions->>RubyGems: Publish gem via rubygems/release-gem@v1
RubyGems-->>Maintainer: Gem v<version> available
end
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 15 minutes and 49 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (7)
📝 WalkthroughWalkthroughThis pull request bumps Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~18 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Hey - I've found 3 issues, and left some high level feedback:
- The new release workflow is driven by a
versioninput and creates/pushes the tag itself, butdocs/RELEASE_PREP.mdstill describes creating the tag via a GitHub Release orrake release; aligning the documented flow with the actual workflow (and avoiding duplicate tag creation) would reduce confusion for future releases. - RELEASE_PREP.md is heavily hard-coded to v1.12.0 (including title, checklist items, and commands), which will make it easy to forget to update for future releases; consider making it version-agnostic or using placeholders so it remains reusable.
- In CHANGELOG.md, SVN support is listed both under
DeprecatedandRemoved, and theDeprecatedentry says it is already removed; it would be clearer to either mark it as deprecated in a prior version or keep it only underRemovedfor v1.12.0.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The new release workflow is driven by a `version` input and creates/pushes the tag itself, but `docs/RELEASE_PREP.md` still describes creating the tag via a GitHub Release or `rake release`; aligning the documented flow with the actual workflow (and avoiding duplicate tag creation) would reduce confusion for future releases.
- RELEASE_PREP.md is heavily hard-coded to v1.12.0 (including title, checklist items, and commands), which will make it easy to forget to update for future releases; consider making it version-agnostic or using placeholders so it remains reusable.
- In CHANGELOG.md, SVN support is listed both under `Deprecated` and `Removed`, and the `Deprecated` entry says it is already removed; it would be clearer to either mark it as deprecated in a prior version or keep it only under `Removed` for v1.12.0.
## Individual Comments
### Comment 1
<location path=".github/workflows/release.yml" line_range="43-50" />
<code_context>
+ - name: Run tests
+ run: bundle exec rake test
+
+ - name: Build gem
+ run: bundle exec rake build
+
+ # Create and push tag
</code_context>
<issue_to_address>
**suggestion (performance):** The explicit `rake build` step might be redundant with `rubygems/release-gem@v1`.
If no later steps use the artifact from `bundle exec rake build`, you can drop this step and rely on `rubygems/release-gem@v1` to build as part of the publish, reducing redundant work in the workflow.
```suggestion
# Build and test
- name: Run tests
run: bundle exec rake test
# Build is handled by rubygems/release-gem@v1 during publish
# Create and push tag
```
</issue_to_address>
### Comment 2
<location path=".github/workflows/release.yml" line_range="50-54" />
<code_context>
+ run: |
+ git config user.name "github-actions[bot]"
+ git config user.email "github-actions[bot]@users.noreply.github.com"
+ git tag -a "v${{ github.event.inputs.version }}" -m "Release v${{ github.event.inputs.version }}"
+ git push origin "v${{ github.event.inputs.version }}"
+
</code_context>
<issue_to_address>
**suggestion:** Tag creation will fail if the tag already exists; consider handling that case explicitly.
If `v${{ github.event.inputs.version }}` already exists (from a prior run or manual tag), `git tag -a` will fail and stop the workflow. To make re-runs idempotent, you could guard tag creation, for example:
```bash
if git rev-parse "v${{ github.event.inputs.version }}" >/dev/null 2>&1; then
echo "Tag v${{ github.event.inputs.version }} already exists; skipping tag creation."
else
git tag -a "v${{ github.event.inputs.version }}" -m "Release v${{ github.event.inputs.version }}"
git push origin "v${{ github.event.inputs.version }}"
fi
```
```suggestion
# Create and push tag
- name: Create release tag
run: |
git config user.name "github-actions[bot]"
git config user.email "github-actions[bot]@users.noreply.github.com"
TAG_NAME="v${{ github.event.inputs.version }}"
if git rev-parse "$TAG_NAME" >/dev/null 2>&1; then
echo "Tag $TAG_NAME already exists; skipping tag creation."
else
git tag -a "$TAG_NAME" -m "Release $TAG_NAME"
git push origin "$TAG_NAME"
fi
```
</issue_to_address>
### Comment 3
<location path="CHANGELOG.md" line_range="63-64" />
<code_context>
+- Add Quick Setup guide, tolerance table, and CI defaults note ([#786a0c1](https://github.com/donv/capybara-screenshot-diff/commit/786a0c1))
+- Add development guide for Docker testing and screenshot recording ([#8a7c981](https://github.com/donv/capybara-screenshot-diff/commit/8a7c981))
+- Add DeepWiki badge to README ([#0929cfa](https://github.com/donv/capybara-screenshot-diff/commit/0929cfa))
+- Add about DEBUG to README ([#c1a53c3](https://github.com/donv/capybara-screenshot-diff/commit/c1a53c3))
+
+### Build/CI
</code_context>
<issue_to_address>
**suggestion (typo):** Clarify the wording of "Add about DEBUG to README".
The phrase "Add about DEBUG to README" is slightly ungrammatical. Consider rewording to "Add information about DEBUG to README" or "Document DEBUG in README".
```suggestion
- Add DeepWiki badge to README ([#0929cfa](https://github.com/donv/capybara-screenshot-diff/commit/0929cfa))
- Document DEBUG in README ([#c1a53c3](https://github.com/donv/capybara-screenshot-diff/commit/c1a53c3))
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
![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
🧹 Nitpick comments (4)
CHANGELOG.md (2)
25-29: SVN removal documented correctly.Listing SVN support under both "Deprecated" and "Removed" with the same commit is slightly redundant for a same-release deprecation+removal. You could consolidate to just "Removed" since there's no migration window, but this is a minor style choice.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@CHANGELOG.md` around lines 25 - 29, The changelog currently lists SVN support under both "Deprecated" and "Removed" (same commit [`#2fe2792`]), so remove the redundant "Deprecated" entry and keep a single "Removed" entry mentioning SVN support removal and its commit; update the headings around the text that reference "Deprecated" and "Removed" to only include the single consolidated "Removed" line referencing commit 2fe2792 to avoid duplicate entries.
8-8: Consider adding an[Unreleased]section header.Following Keep a Changelog convention, there should be an
[Unreleased]section at the top to track changes for the next release. The link reference at line 96 exists but there's no corresponding section header.♻️ Add Unreleased section
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). +## [Unreleased] + ## [v1.12.0] - 2026-04-12🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@CHANGELOG.md` at line 8, Add an `[Unreleased]` top-level section header above the existing release headers in CHANGELOG.md (e.g., insert "## [Unreleased]" before "## [v1.12.0] - 2026-04-12") so future changes can be tracked; also ensure the existing link reference for `[Unreleased]` at the bottom of the file is present and points to the correct compare URL or placeholder, matching the section header name exactly..github/workflows/release.yml (2)
51-56: Consider handling pre-existing tags gracefully.If a tag
v<version>already exists (e.g., from a prior failed run or manual creation),git pushwill fail with a non-obvious error. This is actually a reasonable safeguard against duplicate releases, but you could make it more explicit:♻️ Add explicit tag check for clearer error
- name: Create release tag run: | + if git rev-parse "v${{ github.event.inputs.version }}" >/dev/null 2>&1; then + echo "❌ Tag v${{ github.event.inputs.version }} already exists" + exit 1 + fi git config user.name "github-actions[bot]" git config user.email "github-actions[bot]@users.noreply.github.com" git tag -a "v${{ github.event.inputs.version }}" -m "Release v${{ github.event.inputs.version }}" git push origin "v${{ github.event.inputs.version }}"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml around lines 51 - 56, The current release step creates and pushes an annotated tag without checking for an existing tag, which causes an unclear failure if v${{ github.event.inputs.version }} already exists; update the "Create release tag" step to first check for an existing tag (use git rev-parse --verify "refs/tags/v${{ github.event.inputs.version }}" for local and git ls-remote --tags origin "refs/tags/v${{ github.event.inputs.version }}" for remote) and then either exit with a clear error message via echo and non-zero exit or handle overwrites explicitly, and ensure this logic surrounds the existing git tag -a and git push commands so failures become explicit and recoverable.
33-40: Variable nameRUBY_VERSIONshadows built-in environment variable.The shell variable
RUBY_VERSIONon line 34 shadows the standard Ruby environment variable (commonly set by version managers like rbenv/rvm). While this works because it's scoped to this run block, using a distinct name likeCODE_VERSIONorGEM_VERSIONwould be clearer and avoid potential confusion.♻️ Suggested rename
- RUBY_VERSION=$(ruby -rlib/capybara/screenshot/diff/version -e "puts Capybara::Screenshot::Diff::VERSION") - if [ "$GEM_VERSION" != "$RUBY_VERSION" ]; then + CODE_VERSION=$(ruby -rlib/capybara/screenshot/diff/version -e "puts Capybara::Screenshot::Diff::VERSION") + if [ "$GEM_VERSION" != "$CODE_VERSION" ]; then echo "❌ Version mismatch!" echo "Input version: $GEM_VERSION" - echo "Ruby version: $RUBY_VERSION" + echo "Code version: $CODE_VERSION" exit 1 fi echo "✅ Version verified: $GEM_VERSION"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml around lines 33 - 40, The variable RUBY_VERSION shadows a common environment variable; rename it to a distinct name (e.g., CODE_VERSION) by assigning the ruby -r... command output to CODE_VERSION, then update the conditional to compare GEM_VERSION to CODE_VERSION and update the echo that prints the extracted value to reference CODE_VERSION instead of RUBY_VERSION so all uses (assignment, comparison, and output) match the new variable name.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@docs/RELEASE_PREP.md`:
- Around line 72-84: Docs and workflow are inconsistent: the release.yml (lines
~51-56) creates and pushes the git tag itself, so update RELEASE_PREP.md Step 3
to reflect that you do NOT need to pre-create/select the tag when running the
workflow; specifically change the Step 3 instructions (the bullet that says
"Select the `v1.12.0` tag") to state that the workflow will create and push the
release tag automatically (or alternately, if you prefer to require a
pre-existing tag, modify release.yml to accept and use an existing tag instead);
reference release.yml tag-creation logic and the Step 3 text in RELEASE_PREP.md
to make them consistent.
In `@docs/UPGRADING.md`:
- Around line 372-373: Replace the outdated GitHub Issues URL that points to
"donv/capybara-screenshot-diff" with the correct repository
"snap-diff/snap_diff-capybara" by updating the Issues link text to
"https://github.com/snap-diff/snap_diff-capybara/issues" (the line currently
showing "- **Issues:** [GitHub
Issues](https://github.com/donv/capybara-screenshot-diff/issues)"); ensure only
the URL is changed and the surrounding Markdown format remains the same.
---
Nitpick comments:
In @.github/workflows/release.yml:
- Around line 51-56: The current release step creates and pushes an annotated
tag without checking for an existing tag, which causes an unclear failure if
v${{ github.event.inputs.version }} already exists; update the "Create release
tag" step to first check for an existing tag (use git rev-parse --verify
"refs/tags/v${{ github.event.inputs.version }}" for local and git ls-remote
--tags origin "refs/tags/v${{ github.event.inputs.version }}" for remote) and
then either exit with a clear error message via echo and non-zero exit or handle
overwrites explicitly, and ensure this logic surrounds the existing git tag -a
and git push commands so failures become explicit and recoverable.
- Around line 33-40: The variable RUBY_VERSION shadows a common environment
variable; rename it to a distinct name (e.g., CODE_VERSION) by assigning the
ruby -r... command output to CODE_VERSION, then update the conditional to
compare GEM_VERSION to CODE_VERSION and update the echo that prints the
extracted value to reference CODE_VERSION instead of RUBY_VERSION so all uses
(assignment, comparison, and output) match the new variable name.
In `@CHANGELOG.md`:
- Around line 25-29: The changelog currently lists SVN support under both
"Deprecated" and "Removed" (same commit [`#2fe2792`]), so remove the redundant
"Deprecated" entry and keep a single "Removed" entry mentioning SVN support
removal and its commit; update the headings around the text that reference
"Deprecated" and "Removed" to only include the single consolidated "Removed"
line referencing commit 2fe2792 to avoid duplicate entries.
- Line 8: Add an `[Unreleased]` top-level section header above the existing
release headers in CHANGELOG.md (e.g., insert "## [Unreleased]" before "##
[v1.12.0] - 2026-04-12") so future changes can be tracked; also ensure the
existing link reference for `[Unreleased]` at the bottom of the file is present
and points to the correct compare URL or placeholder, matching the section
header name exactly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 68eef8ef-5768-4dcf-9513-e0c815bc0c1f
📒 Files selected for processing (5)
.github/workflows/release.ymlCHANGELOG.mddocs/RELEASE_PREP.mddocs/UPGRADING.mdlib/capybara/screenshot/diff/version.rb
pftg
force-pushed
the
emdash/feat-re-review-git-history-8yi
branch
from
0dfe17b to
a6f9978
Compare
Add CHANGELOG.md with 71 commits since v1.11.0. Add docs/UPGRADING.md migration guide. Add docs/RELEASE_PREP.md release checklist. Update .github/workflows/release.yml for one-click release. Bump version to 1.12.0. Fix outdated repository URLs in all docs. Co-authored-by: Qwen-Coder <qwen-coder@alibabacloud.com>
pftg
force-pushed
the
emdash/feat-re-review-git-history-8yi
branch
from
8b6718b to
62a74cf
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
1 participant
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.
Summary
docs/RELEASE_PREP.md)docs/UPGRADING.md)Changes
.github/workflows/release.yml: Enhanced release workflow with version verification and simplified one-click processCHANGELOG.md: Added v1.12.0 release notesdocs/RELEASE_PREP.md: New release preparation checklist and guidedocs/UPGRADING.md: New comprehensive upgrade guide for userslib/capybara/screenshot/diff/version.rb: Version bump to 1.12.0Summary by Sourcery
Prepare the 1.12.0 release and streamline the automated release process.
New Features:
Enhancements:
CI:
Documentation:
Summary by CodeRabbit
Documentation
Chores