Exclude .gem files from git and gemspec files list

[justin808]

Summary

• Adds *.gem to .gitignore to prevent built gem files from being staged by git (e.g., during release-it's commit flow)
• Adds .gem file exclusion to the gemspec's reject filter as a safety net

Fixes the release script failure where bundle install in spec/dummy fails with RubyGems' validate_self_inclusion_in_files_list error: shakapacker-9.6.0.rc.2 contains itself (shakapacker-9.6.0.rc.2.gem), check your files list

Test plan

• Run bundle exec gem build shakapacker.gemspec and verify the .gem file is gitignored
• Run a dry-run release to verify the full flow works

🤖 Generated with Claude Code

---

Note

Low Risk
Small packaging/release hygiene change limited to .gitignore and gemspec file selection logic.

Overview
Prevents built RubyGems artifacts from being accidentally committed or packaged by ignoring *.gem outputs.

Updates shakapacker.gemspec’s s.files filter to explicitly reject .gem files as a safety net, avoiding self-inclusion errors during gem build/release flows.

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

Summary by CodeRabbit

• Chores
  • Updated project configuration to exclude built gem files from version control and package distribution.

[coderabbitai]

Important

Review skipped

Review was skipped due to path filters

⛔ Files ignored due to path filters (1)

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

CodeRabbit blocks several paths by default. You can override this behavior by explicitly including those paths in the path filters. For example, including **/dist/** will override the default block on the dist directory, by removing the pattern from both the lists.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 75c4f8d6-a3fd-4069-b344-1edf8db33bb7

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

Walkthrough

The pull request adds exclusion patterns for built gem files (*.gem) to both the gitignore configuration and the gemspec file manifest, ensuring compiled gems are not tracked in version control or distributed with the package.

Changes

Cohort / File(s)	Summary
Gem File Exclusions .gitignore, shakapacker.gemspec	Added patterns to exclude .gem files (built gems) in gitignore and updated the gemspec file filtering logic to skip .gem files from the manifest.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~3 minutes

Poem

🐰✨ A gem of a change, so clean and so neat,
We hide away .gem files, oh what a treat!
In gitignore and spec, the pattern does dance,
Built gems tucked away, they won't get a glance! 💎

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately reflects the main objective of the pull request, which is to exclude .gem files from both .gitignore and the gemspec files list to prevent build artifacts from being included in repository and packaging workflows.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ 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-release-script

---

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.}

[claude]

Review

Clean, minimal fix for a real release-workflow bug. Both changes are correct and well-motivated.

.gitignore -- adding *.gem is the right primary fix. git ls-files (used in the gemspec) only lists tracked files, so gitignoring .gem files is sufficient to prevent self-inclusion in the normal build flow.

shakapacker.gemspec -- the f.end_with?(".gem") guard is a good defensive layer. It protects against the edge case where someone force-adds a .gem file with git add -f (e.g., during a release tool's automated commit step before the gitignore rule kicks in), which is exactly the scenario described in the PR. Belt-and-suspenders is appropriate here.

No issues found. LGTM.

[greptile-apps]

Greptile Summary

This PR fixes a release-script failure where bundle install in spec/dummy would error with RubyGems' validate_self_inclusion_in_files_list error (shakapacker contains itself). The root cause was that the built .gem file could be staged by release-it's commit flow, causing git ls-files (used in s.files) to include the artifact, which RubyGems then detected as self-inclusion.

• .gitignore: Adds *.gem to prevent built gem artifacts from ever being picked up by git in any release or build step.
• shakapacker.gemspec: Extends the s.files reject block with f.end_with?(".gem") as a belt-and-suspenders guard — if a .gem file were somehow committed or force-staged, it would still be excluded from the packaged gem's file list.

Confidence Score: 5/5

• Safe to merge — minimal, targeted fix with no risk of regressions.
• Both changes are additive-only (a new gitignore pattern and an extra reject condition). The .gitignore entry prevents .gem artifacts from being tracked; the gemspec guard is a redundant safety net. Neither change affects runtime behaviour, test logic, or any existing file selection for legitimate gem contents.
• No files require special attention

Important Files Changed

Filename	Overview
.gitignore	Adds *.gem pattern to prevent built gem files from being tracked by git during release flows.
shakapacker.gemspec	Extends the s.files reject filter with f.end_with?(".gem") as a safety net, preventing any tracked .gem files from being packaged inside the gem.

Sequence Diagram

sequenceDiagram
    participant Dev as Developer
    participant ReleaseIt as release-it
    participant Git as git
    participant Bundler as bundler
    participant RubyGems as RubyGems

    Dev->>ReleaseIt: Run release script
    ReleaseIt->>RubyGems: gem build shakapacker.gemspec
    RubyGems-->>Dev: shakapacker-x.y.z.gem (created in root)

    Note over Git: *.gem now in .gitignore
    ReleaseIt->>Git: git add / commit (bump version, etc.)
    Git-->>ReleaseIt: *.gem ignored — not staged

    Note over RubyGems: s.files filter also rejects .gem files
    ReleaseIt->>RubyGems: gem build shakapacker.gemspec (final)
    RubyGems-->>ReleaseIt: gem built without self-inclusion

    ReleaseIt->>Bundler: bundle install (in spec/dummy)
    Bundler-->>ReleaseIt: Success — no validate_self_inclusion error

Loading

_{Last reviewed commit: 8d88a85}

[claude]

Review: Exclude .gem files from git and gemspec

This is a clean, focused fix. The root cause (RubyGems' validate_self_inclusion_in_files_list check failing during release) is correctly addressed.

Approach is sound:

• Adding *.gem to .gitignore is the primary fix — it prevents built artifacts from being tracked in the first place.
• The f.end_with?(".gem") guard in the gemspec is a useful belt-and-suspenders safety net. Technically redundant since git ls-files only lists tracked files, but it future-proofs against any edge case where a .gem file ends up tracked (e.g., before this PR was merged, or in a fresh clone with stale index state).

Minor observation:
The spec/dummy/Gemfile.lock jumps from 9.6.0.rc.1 → 9.6.0.rc.3, skipping rc.2. This is expected since rc.2 was broken by the self-inclusion bug, but worth noting for release notes / tag history.

No CHANGELOG entry needed per project guidelines (release infrastructure fix, not user-visible behavior change).

LGTM ✓

[claude]

This is a clean, well-targeted fix for a real release-flow problem.

Root cause fix - Adding *.gem to .gitignore prevents built artifacts from entering the git working tree during release-it's commit step, which is exactly what triggers the validate_self_inclusion_in_files_list error.

Defense in depth - The end_with?(".gem") guard in the gemspec is technically redundant (since git ls-files already respects .gitignore, so gitignored files never appear in its output), but it is a harmless safety net for edge cases where a gem file might be pre-existing tracked content.

Gemfile.lock - The version reflects the correct rc.2 state after the rc.3 bump was reverted. This is appropriate.

Minor observation - The .gitignore already has /pkg (line 2), which is the conventional gem build output location. The new *.gem rule is broader and necessary because release-it may write the .gem file to the repo root rather than pkg/. The broader pattern is the right call here.

No issues with correctness, security, or performance. Good to merge.