Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Track Gemfile.lock at the repository #18992

Merged
merged 1 commit into from
Feb 18, 2015
Merged

Conversation

rafaelfranca
Copy link
Member

The main reason is to make bisect easier.

In some points, we have a lot of git dependencies. Since we don't have
the information of which commit we are referring to, bundler get the
latest commit of the master branch of the dependency. This sometimes
returns a version that is not compatible with Rails anymore, making the
tests fail and the harder to identify the commit that introduced a bug.

Also this will make sure that a contributor will always get a set of
dependencies that are passing with our tests.

In our CI server we delete the lock file to make sure we are always
testing against the newest release of our dependencies.

The main reason is to make bisect easier.

In some points, we have a lot of git dependencies. Since we don't have
the information of which commit we are referring to, bundler get the
latest commit of the master branch of the dependency. This sometimes
returns a version that is not compatible with Rails anymore, making the
tests fail and the harder to identify the commit that introduced a bug.

Also this will make sure that a contributor will always get a set of
dependencies that are passing with our tests.

In our CI server we delete the lock file to make sure we are always
testing against the newest release of our dependencies.
@rafaelfranca
Copy link
Member Author

cc @rails/rails-committers @rails/rails-issues

@sgrif
Copy link
Contributor

sgrif commented Feb 18, 2015

👍

@eileencodes
Copy link
Member

I like anything that makes bisecting easier 😁 Thanks @rafaelfranca!

@guilleiguaran
Copy link
Member

I'm 👍 on this :)

@dhh
Copy link
Member

dhh commented Feb 18, 2015

I weighed in before understand the issue on the other ticket, but after Rafael educating me, I'm 👍

@lukaszx0
Copy link
Member

I'm in! 👍

On Wed, Feb 18, 2015 at 6:38 PM, David Heinemeier Hansson <
notifications@github.com> wrote:

I weighed in before understand the issue on the other ticket, but after
Rafael educating me, I'm [image: 👍]


Reply to this email directly or view it on GitHub
#18992 (comment).

@chancancode
Copy link
Member

❤️

@carlosantoniodasilva
Copy link
Member

💚💛❤️💙💜

@dmathieu
Copy link
Contributor

💯

rafaelfranca added a commit that referenced this pull request Feb 18, 2015
Track Gemfile.lock at the repository
@rafaelfranca rafaelfranca merged commit a845abd into master Feb 18, 2015
@rafaelfranca rafaelfranca deleted the rm-track-lock-file branch February 18, 2015 17:52
rafaelfranca added a commit that referenced this pull request Feb 18, 2015
Track Gemfile.lock at the repository
@arthurnn
Copy link
Member

🎉

@vipulnsward
Copy link
Member

We should document, whats acceptable when updating the file in contributing guide.

@arthurnn
Copy link
Member

Only issue I see about this is:

This sometimes
returns a version that is not compatible with Rails anymore, making the
tests fail and the harder to identify the commit that introduced a bug.

The test will still fail on travis-ci, and it would be still hard to identify the problem.

rafaelfranca added a commit that referenced this pull request Feb 18, 2015
Track Gemfile.lock at the repository
@rafaelfranca
Copy link
Member Author

@arthurnn at CI side it will still fail but if it is passing locally we will at least know it is because of of the dependencies.

@vipulnsward good point about documenting. I'll write something.

@arunagw
Copy link
Member

arunagw commented Feb 18, 2015

👍

@fxn
Copy link
Member

fxn commented Feb 18, 2015

🚀

@amatsuda
Copy link
Member

🤘

@dalizard
Copy link

And what was the reason Gemfile.lock not to be under version control?

P.S. Apologies for extending the topic further...

@rafaelfranca
Copy link
Member Author

@dalizard
Copy link

@rafaelfranca Thanks!

senny added a commit to rails/rails-perftest that referenced this pull request Apr 24, 2015
This establishes a consistent environment for contributors.
See rails/rails#18992 for more details.
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.

None yet