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

Track Gemfile.lock at the repository #18992

merged 1 commit into from Feb 18, 2015

Conversation

@rafaelfranca
Copy link
Member

@rafaelfranca rafaelfranca commented Feb 18, 2015

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 rafaelfranca force-pushed the rm-track-lock-file branch from aeb3e25 to 9c6da15 Feb 18, 2015
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 rafaelfranca force-pushed the rm-track-lock-file branch from 9c6da15 to b1edc37 Feb 18, 2015
@rafaelfranca
Copy link
Member Author

@rafaelfranca rafaelfranca commented Feb 18, 2015

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

@sgrif
Copy link
Contributor

@sgrif sgrif commented Feb 18, 2015

👍

@eileencodes
Copy link
Member

@eileencodes eileencodes commented Feb 18, 2015

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

@guilleiguaran
Copy link
Member

@guilleiguaran guilleiguaran commented Feb 18, 2015

I'm 👍 on this :)

@dhh
Copy link
Member

@dhh 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

@lukaszx0 lukaszx0 commented Feb 18, 2015

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

@chancancode chancancode commented Feb 18, 2015

❤️

@carlosantoniodasilva
Copy link
Member

@carlosantoniodasilva carlosantoniodasilva commented Feb 18, 2015

💚💛❤️💙💜

@dmathieu
Copy link
Contributor

@dmathieu dmathieu commented Feb 18, 2015

💯

rafaelfranca added a commit that referenced this issue Feb 18, 2015
Track Gemfile.lock at the repository
@rafaelfranca rafaelfranca merged commit a845abd into master Feb 18, 2015
2 checks passed
@rafaelfranca rafaelfranca deleted the rm-track-lock-file branch Feb 18, 2015
rafaelfranca added a commit that referenced this issue Feb 18, 2015
Track Gemfile.lock at the repository
@arthurnn
Copy link
Member

@arthurnn arthurnn commented Feb 18, 2015

🎉

@vipulnsward
Copy link
Member

@vipulnsward vipulnsward commented Feb 18, 2015

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

@arthurnn
Copy link
Member

@arthurnn arthurnn commented Feb 18, 2015

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 issue Feb 18, 2015
Track Gemfile.lock at the repository
@rafaelfranca
Copy link
Member Author

@rafaelfranca rafaelfranca commented Feb 18, 2015

@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 arunagw commented Feb 18, 2015

👍

@fxn
Copy link
Member

@fxn fxn commented Feb 18, 2015

🚀

@amatsuda
Copy link
Member

@amatsuda amatsuda commented Feb 18, 2015

🤘

@dalizard
Copy link

@dalizard dalizard commented Feb 18, 2015

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

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

@dalizard
Copy link

@dalizard dalizard commented Feb 18, 2015

@rafaelfranca Thanks!

senny added a commit to rails/rails-perftest that referenced this issue 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
Linked issues

Successfully merging this pull request may close these issues.

None yet