Suggestion: .ruby_version shouldn't be in .gitignore

[nieltg]

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

1. Bump webmock dependency version to 3.6.
2. Lock Ruby version to Ruby 2.5.

By specifying .ruby-version, user can clone this repository and be able to run the test.

[fadlinurhasan]

How about Gemfile.lock? I think we also need include this to gitignore. wdyt?

[nieltg]

@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

[giosakti]

Yes Gemfile.lock should be committed