Fix release process not updating spec/dummy version in commit

[justin808]

Summary

• The release process updates spec/dummy lockfiles before release-it runs, but release-it only reliably stages files it modifies (package.json). Other working tree changes (version.rb, Gemfile.lock, spec/dummy lockfiles) were not being included in the release commit.
• Adds an explicit git add -A after all lockfile updates and before release-it runs, ensuring all release-related changes are pre-staged and included in the release commit.
• Updates spec/dummy/Gemfile.lock from 9.6.0 to 9.6.1 to fix the current CI failure.

Test plan

• Verify CI passes with the updated spec/dummy/Gemfile.lock
• Run bundle exec rake "create_release[9.6.2,true]" (dry run) to verify the release process stages all files correctly

🤖 Generated with Claude Code

---

Note

Low Risk
Small change to release automation (adds explicit staging) plus a lockfile version bump; minimal runtime impact outside the release workflow.

Overview
Fixes the release rake task so the release commit reliably includes all version/lockfile changes. After bumping and updating spec/dummy dependencies, it now runs git add -A before invoking release-it.

Updates spec/dummy/Gemfile.lock to reference shakapacker 9.6.1 (from 9.6.0).

^{Written by Cursor Bugbot for commit bfe1dab. Configure here.}

Summary by CodeRabbit

Bug Fixes

• Release process now explicitly stages version and dependency lockfiles before creating release commits, ensuring all necessary release-related files are consistently and reliably included in release commits.

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 8969ab04-af8e-4c68-80ae-733e7c1fd997

📥 Commits

Reviewing files that changed from the base of the PR and between 122b4ba and 88ad95d.

⛔ Files ignored due to path filters (1)

• spec/dummy/Gemfile.lock is excluded by !**/*.lock

📒 Files selected for processing (1)

• rakelib/release.rake

---

Walkthrough

The pull request modifies the release rake task to explicitly stage version.rb, Gemfile.lock, and spec/dummy lockfiles (Gemfile.lock, yarn.lock, package-lock.json) before the release commit, replacing an implicit assumption that git add would automatically include all working tree changes.

Changes

Cohort / File(s)	Summary
Release Process rakelib/release.rake	Added explicit git add command to stage version.rb, Gemfile.lock, and spec/dummy lockfiles (Gemfile.lock, yarn.lock, package-lock.json) prior to release commit, ensuring these files are reliably included in the commit.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• Fix release script: update spec/dummy lockfile before release-it #957: Also modifies rakelib/release.rake to ensure spec/dummy lockfiles are properly handled during release commits, using a complementary approach to version control lockfile inclusion.

Poem

🐰 A rabbit hops with glee so bright,
No more implicit, all is right!
With staging clear and files in place,
The release runs at steady pace! 🎯✨

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch jg/fix-spec-dummy-version-sync

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[greptile-apps]

Greptile Summary

This PR fixes a gap in the release process where file changes made before release-it runs — such as version.rb, Gemfile.lock, and spec/dummy lockfiles — were not reliably included in the release commit because release-it only stages the files it directly modifies (package.json). The fix adds an explicit git add -A after all lockfile updates and before the release-it invocation, ensuring all pre-release changes are staged. The spec/dummy/Gemfile.lock version bump from 9.6.0 to 9.6.1 is an accompanying fix for the immediate CI failure.

Key changes:

• Removes the now-incorrect inline comment claiming release-it does git add .
• Adds git add -A (run from release_root) after all lockfile update steps, so all working-tree changes are staged before release-it makes its commit
• Bumps the shakapacker path-dependency version in spec/dummy/Gemfile.lock from 9.6.0 → 9.6.1

Confidence Score: 5/5

• This PR is safe to merge — the change is minimal, well-scoped, and correctly addresses a documented release-process gap.
• The git add -A is placed at exactly the right point in the sequence (after all lockfile mutations, before release-it) and operates on the correct directory (release_root). For dry runs, with_release_checkout already isolates work in a throwaway git worktree, so the staging has no side-effects on the developer's local checkout. The Gemfile.lock bump is a straightforward version update with no dependency conflicts.
• No files require special attention.

Important Files Changed

Filename	Overview
rakelib/release.rake	Adds an explicit git add -A after all lockfile updates and before release-it runs, ensuring all release-related changes (version.rb, Gemfile.lock, spec/dummy lockfiles) are pre-staged and included in the release commit. Also removes a now-incorrect comment claiming release-it does git add ..
spec/dummy/Gemfile.lock	Bumps the local shakapacker path dependency version from 9.6.0 to 9.6.1 to fix a CI failure; all other dependency versions remain unchanged.

Sequence Diagram

sequenceDiagram
    participant Rake as rake create_release
    participant WC as with_release_checkout
    participant Root as release_root
    participant Dummy as spec/dummy

    Rake->>WC: enter worktree (dry-run) or use gem_root
    WC->>Root: git pull --rebase
    Root->>Root: gem bump --no-commit
    Root->>Root: bundle install
    Root->>Dummy: bundle install
    Root->>Dummy: yarn install
    Root->>Dummy: npm install
    Note over Root: NEW: git add -A<br/>Stages version.rb, Gemfile.lock,<br/>and spec/dummy lockfiles
    Root->>Root: validate gem version
    Root->>Root: release-it with --no-git.requireCleanWorkingDir
    Note over Root: release-it commits all<br/>pre-staged files + package.json
    Root->>Root: gem release

Loading

_{Last reviewed commit: bfe1dab}

[claude]

Review

The fix is correct and well-motivated. A few observations:

What works well:

• Pre-staging with git add -A before release-it is the right approach. Since release-it is already invoked with --no-git.requireCleanWorkingDir, it won't reject the pre-staged index, and it will include those changes in its release commit.
• The dry-run path is safe: with_release_checkout creates a throw-away worktree for dry runs, so git add -A there has no lasting effect.
• ensure_clean_worktree! at the top of perform_release prevents genuinely unrelated working-tree changes from being swept in by the git add -A in the real release path.

One minor concern — git add -A picks up untracked files:

git add -A stages untracked files as well as modifications. Everything generated by the release process (gem bump, bundle install, the spec/dummy installs) should be tracked, so in practice this is fine. But if any install step deposits an unexpected untracked file (e.g. a generated lockfile outside the known paths), it will silently be included in the release commit. A narrower alternative would be:

git add version.rb Gemfile.lock spec/dummy/Gemfile.lock spec/dummy/yarn.lock spec/dummy/package-lock.json

That said, this is a low-risk internal tooling script and git add -A is pragmatic here. Happy to merge as-is if you're comfortable with the trade-off.

spec/dummy/Gemfile.lock bump: Straightforward CI fix, looks good.

[claude]

Review: Fix release process not updating spec/dummy version in commit

The fix is correct and well-reasoned. A few observations for the record:

What's good

• Dry-run safety is preserved. with_release_checkout creates a temporary git worktree for dry runs, so the explicit git add runs inside that throwaway worktree rather than dirtying the maintainer's real checkout.
• Explicit file list is the right trade-off. It's safer than git add -A (which could accidentally stage unintended changes) while still covering all the files modified by the release process.
• Correct ordering. The git add happens after all lockfile updates (bundle install, yarn install, npm install) and before release-it, so release-it will find everything pre-staged.

Minor concern to watch

The explicit file list (version.rb Gemfile.lock spec/dummy/Gemfile.lock spec/dummy/yarn.lock spec/dummy/package-lock.json) requires manual maintenance. If the release process ever produces additional files that need to be committed (e.g., a root yarn.lock update), this list would need to be updated separately. A comment in the code pointing back to this rationale would help future maintainers remember why git add -A was intentionally avoided here.

No issues

• All listed files exist in the repo and are tracked by git, so git add won't fail on missing paths.
• The spec/dummy/Gemfile.lock bump from 9.6.0 → 9.6.1 is correct and needed to unblock CI.

Overall: clean fix, low risk, correct behavior. ✓

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 88ad95de16

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Stage the correct version file path

This staging command will fail on every release because version.rb is not a tracked path at the repo root (the gem version file is lib/shakapacker/version.rb), and git add exits non-zero when any pathspec is missing. In practice perform_release stops at this line with fatal: pathspec 'version.rb' did not match any files, so both dry-run and real releases abort before release-it runs.

Useful? React with 👍 / 👎.