Suggestion: .ruby_version shouldn't be in .gitignore
Opened this issue · 3 comments
.ruby_version
should be version controlled, so tools like rbenv can automatically select Ruby version used in this project.
.ruby-version
is ignored for library projects, not applications.
.ruby_version
is ignored for library projects because libraries are included in various Ruby projects which also run on various Ruby versions. BaritoMarket itself is actually a standalone web application, not a library that needs to be embedded in various Ruby projects.
Reference: https://github.com/github/gitignore/blob/master/Ruby.gitignore#L46-L50
BaritoMarket's unit tests can't run on latest Ruby version.
There's an issue with webmock and Ruby 2.6, as can be seen in bblimke/webmock#786. This causes unit tests will yield this error when run in Ruby 2.6:
Failure/Error: visit root_path
ArgumentError:
unknown keyword: write_timeout
# /usr/share/ruby/net/http.rb:1002:in `new'
# /usr/share/ruby/net/http.rb:1002:in `connect'
# /usr/share/ruby/net/http.rb:930:in `do_start'
# /usr/share/ruby/net/http.rb:1228:in `get'
# /usr/share/ruby/net/http.rb:605:in `start'
# ./spec/features/barito_app_management/update_barito_app_spec.rb:30:in `block (4 levels) in <top (required)>'
There are two ways to solve this problem:
- Bump webmock dependency version to 3.6.
- Lock Ruby version to Ruby 2.5.
By specifying .ruby-version
, user can clone this repository and be able to run the test.
How about Gemfile.lock? I think we also need include this to gitignore. wdyt?
@fadlinurhasan
Please elaborate more on why Gemfile.lock
should be Git ignored.
For me, the current state is already good. Gemfile.lock
shouldn't be ignored because if it's being ignored, every bundle install
will download different versions of indirect Gem dependencies.
The objective is to make development and production environment to be as similar as possible, right? So there'll be fewer errors regarding different environment configurations.
Reference: https://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile
Yes Gemfile.lock should be committed