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

Add ruby 2.7 and update some gems #1508

Merged
merged 30 commits into from
Jan 24, 2022

Conversation

dounokouno
Copy link
Contributor

Hi,

I've made a lot of corrections and it may be difficult to confirm, but please review. (If you would like to separate the PRs for the revisions, please comment to that effect.)

I have modified the following:

  • Updated bundler version to v2.2.27.
  • Updated Rails version to v4.2.11.3.
  • Updated puma version to v4.3.8.
  • mini_racer has fixed the version to v0.3.1.
    • I forgot why, but I think it was some other gem dependency.
  • Updated rubocop version to v0.71.0.
    • This is because this version supports Ruby 2.7.
  • Other gems have also been updated. See the diffs in Gemfile.lock for more details.
  • With the rubocop upgrade, some of the cops were carved out into separate gems, so I added those gems. The following two gems have been added.
    • rubocop-performance
    • ubocop-rails
  • Added bigdecimal gem to support Ruby v2.7.
  • Added app/assets/config/manifest.js, probably because the sprockets update required it.

And I have not modified the following:

  • Did not raise the version of rubocop more than necessary.
  • Did not correct the pointed out part of rubocop.

Next upcoming my tasks:

  • Fix docker-compose.yml.
    • I'm going to use Ruby v2.7 and MongoDB v4.4 or v5.0 and try to run it for a week or so in my production environment.
  • Change the browser of feature spec to headless chrome.
    • This may be a good idea for the next version of errbit.

I've already confirmed that all tests are passing in circleCI.

Screenshot 2021-09-13 8 52 59

Thank you.

@stevecrozz
Copy link
Member

This is great @dounokouno! I think personally, my vote would be to make more of a 'hard switch.' Now that docker rules the world, I don't see much point in officially supporting more than one version of Ruby. So if you'd like, you are welcome to drop Ruby 2.5 and 2.6 support in this PR.

Either way, we'll need a change to the docs which is README.md and any other file that references a Ruby version in the ./docs folder.

@dounokouno
Copy link
Contributor Author

Do not we need to consider the case where we want to run errbit application (mainly puma) and MongoDB on separate servers or instances instead of using docker-compose? For example, we may want to use Amazon DocumentDB to persist our data. We may also want to use Amazon EC2 or Amazon ECS for redundancy in our errbit application.

Of course, the contents of docker-compose.yml, various configuration files, and other source code are all open to the public, so if you want to have such a configuration, we can just set it that way. I think there is also the idea of leaving matrix tests for various patterns for those people.

I'm currently using docker-compose to operate it, and I think it's possible to deal with redundancy when it actually becomes necessary.

For the time being, I just wanted to tell you that there are such people, and that there is such a way of thinking, so if @stevecrozz and other main maintainers can make the final decision, that's okay 🙆‍♂️

So, if you comment that you should keep only one version of Ruby 2.7 and MongoDB, I would like to do so 👍

Excuse me for the long sentence. thank you for reading it until the very end.

@stevecrozz
Copy link
Member

These are good thoughts. My impression is that most people do not deploy errbit with this exact docker-compose.yml file. It is here mainly as an example. Now, the versions of Ruby and Mongo to support I think are two separate discussions. My thought here is we don't need to support more than one version of Ruby. docker build builds an image that includes the right version of Ruby and I think that's all we need.

Regarding mongo, that is a bit different and I'd like users to have the flexibility to use with a variety of mongo versions and hopefully the AWS lookalike (DocumentDB). We barely use any mongo features and I can't remember the last time we had a mongo version related issue. So how many versions of mongo should we test? My instinct is to say we should test 2 versions, the lowest officially supported version and the highest one. So it looks like that is 4.0 and 5.0. Can you think of any good reason to also test 4.2 and 4.4? It seems like a waste of CPU cycles to me.

@dounokouno
Copy link
Contributor Author

hi,

Thank you for your reply.

I agree with the idea of supported versions of ruby. I think the need to test multiple versions is low.

I don't know much about the supported versions of MongoDB, so I'll do some research.

@stevecrozz
Copy link
Member

No worries. @dounokouno. We can carry on for now without changing our mongodb support matrix. Let's just make the Ruby support change and come back to mongo another time.

@dounokouno
Copy link
Contributor Author

@stevecrozz

Thank you for your reply. And I'm sorry for the late reply.

Currently, I'm a little busy personally, and I haven't been able to continue the PR corrections or verify the operation with docker-compose. Once the current busy situation has subsided, I will continue to revise this PR. I think I'll be back in a while, so please wait for a while.

Thank you.

@burnettk burnettk merged commit 4e24589 into errbit:main Jan 24, 2022
@dounokouno
Copy link
Contributor Author

@burnettk Thank you for your supports and merging 🎉

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

3 participants