Skip to content

Conversation

@F3rry-PCOR
Copy link
Collaborator

This PR removes the exclusion of gemfile.lock from .gitignore, which was a mistake I did in my previous PR.

Ticket: https://procoretech.atlassian.net/browse/PIE-39

@F3rry-PCOR F3rry-PCOR self-assigned this Nov 14, 2025
@F3rry-PCOR F3rry-PCOR merged commit 1deac29 into main Nov 14, 2025
5 checks passed
@F3rry-PCOR F3rry-PCOR deleted the PIE-39-fix-pie-36 branch November 14, 2025 14:41
@F3rry-PCOR
Copy link
Collaborator Author

Just adding a commentary/reminder

We should always check the Gemfile.lock into a GitHub project (or any version control system) for a Ruby application.

Importance of Gemfile.lock
The Gemfile.lock file is crucial for best practices because it ensures dependency consistency across different environments (development, testing, staging, and production) and among all developers working on the project.

Here's why it's essential:

  • Reproducible Builds: It locks the exact versions of all gems, including dependencies of your declared gems, that are known to work with your application. Without it, running bundle install could pull in newer, potentially incompatible, gem versions, breaking your application.
  • Preventing "Works on My Machine": It eliminates version drift. Every developer and server uses the identical, verified set of gems specified in the lock file.
  • Clear Review Process: When a gem version needs updating, the changes in the Gemfile.lock are explicit, allowing for a clear review of which dependencies were updated and why (e.g., security fixes or new features).

The general rule is: If your project is an application (e.g., a Rails app, Sinatra app, or a CLI tool meant for end-users), check in the Gemfile.lock.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants