Refresh Gemfile.lock

[pvalena]

Log from doing the Refresh and TEST:
https://gist.github.com/pvalena/cc6bf3cfad746d944a287aa4bd6486a1

The Gemfile.lock refresh was done in ubi8/ruby-2.5 container. No changes were made to Gemfile / other contstraints.

@voxik @junaruga PTAL.

[pvalena]

@yselkowitz @pkubatrh is there any way we could test this PR with s2i-ruby-container? (I have no access to OpenShift instance.)

[yselkowitz]

for v in 25 26 27; do s2i build -e RAILS_ENV=test -r refresh https://github.com/pvalena/rails-ex registry.redhat.io/rhscl/ruby-$v-rhel7 rails-ex-$v; done

[pvalena]

for v in 25 26 27; do s2i build -r refresh https://github.com/pvalena/rails-ex registry.redhat.io/rhscl/ruby-$v-rhel7 rails-ex-$v; done

Yes, I'd do that, apart from s2i not working with podman on my Fedora (openshift/source-to-image#966 (comment)).

I've tried once more with most recent rawhide, but the issue is still same. The s2i doesn't know any ''--as-dockerfile'' as well.

[pvalena]

@yselkowitz off course you'd also need to run the app and check for its "health".

[pvalena]

@pkubatrh did we have any means we could try this PR with some PR on s2i-ruby?

[yselkowitz]

I get the following with 2.7:

/opt/rh/rh-ruby27/root/usr/share/rubygems/rubygems.rb:275:in `find_spec_for_exe': Could not find 'bundler' (1.16.1) required by your /opt/app-root/src/Gemfile.lock. (Gem::GemNotFoundException)
To update to the latest version installed on your system, run `bundle update --bundler`.
To install the missing version, run `gem install bundler:1.16.1`
	from /opt/rh/rh-ruby27/root/usr/share/rubygems/rubygems.rb:294:in `activate_bin_path'
	from /opt/rh/rh-ruby27/root/usr/bin/bundle:23:in `<main>'
Build failed
ERROR: An error occurred: non-zero (13) exit code from registry.redhat.io/rhscl/ruby-27-rhel7

Builds with 2.5 and 2.6 complete and appear to function correctly, once RAILS_ENV is defined.

[junaruga]

/opt/rh/rh-ruby27/root/usr/share/rubygems/rubygems.rb:275:in `find_spec_for_exe': Could not find 'bundler' (1.16.1) required by your /opt/app-root/src/Gemfile.lock. (Gem::GemNotFoundException)

I am not sure if how the following part in Gemfile.lock affects the error, and not sure if the program works without the part in Gemfile, and not sure how the part worked in the past considering the error you faced above.

 BUNDLED WITH
   1.16.1

By the way, the bundled bundle's version in Ruby 2.7.1 is 2.1.4.

$ which bundle
/usr/local/ruby-2.7.1/bin/bundle

$ bundle -v
Bundler version 2.1.4

Here is the result I created the Gemfile.lock on my local now.
i18n part is no problem.

$ bundle lock

$ git diff
diff --git a/Gemfile.lock b/Gemfile.lock
index 0a975c4..4db8ac6 100644
--- a/Gemfile.lock
+++ b/Gemfile.lock
@@ -66,7 +66,7 @@ GEM
     ffi (1.13.1)
     globalid (0.4.2)
       activesupport (>= 4.2.0)
-    i18n (1.8.3)
+    i18n (1.8.4)
       concurrent-ruby (~> 1.0)
     jbuilder (2.10.0)
       activesupport (>= 5.0.0)
@@ -193,4 +193,4 @@ DEPENDENCIES
   web-console (>= 3.3.0)
 
 BUNDLED WITH
-   1.16.1
+   2.1.4

[junaruga]

is there any way we could test this PR with s2i-ruby-container? (I have no access to OpenShift instance.)

As another topic, it might be useful for this repository to have CI like s2i-ruby-container 's .travis.yml.

[junaruga]

I tried to test the Gemfile.lock. Here is the result of running tests on my local Fedora 32 with Ruby 2.7.1. This might be included in this repository's CI, if the tests are practically used.

$ sudo dnf -y install sqlite-devel postgresql-server libpq-devel nodejs

$ bundle install --path vendor/bundle

$ bundle exec rake test
...
1 runs, 1 assertions, 0 failures, 0 errors, 0 skips

[pvalena]

is there any way we could test this PR with s2i-ruby-container? (I have no access to OpenShift instance.)

As another topic, it might be useful for this repository to have CI like s2i-ruby-container 's .travis.yml.

Actually, as this is only used for s2i-ruby-container (or similar), it would make sense to test it on s2i-ruby-container repo. Now we can either test itmanually/locally, or using a CI - by creating a PR with the change.

I think this could be done with git submodules, adding one to https://github.com/sclorg/s2i-ruby-container/tree/master/2.7/test. Alternatively, and Ideally, it may be tested by some OpenShift test. But I'm unsure how to create either of those.

@pkubatrh WDYT?

[pvalena]

$ bundle exec rake test

@junaruga Thanks for testing! I'm not sure however this accurately approximates s2i build though.

[junaruga]

Actually, as this is only used for s2i-ruby-container (or similar), it would make sense to test it on s2i-ruby-container repo.

Even when this repo is only used for s2i-ruby-container, the we want to check the modification such as this PR at the PR timing, do not we? Test fast, fail fast. If there was the CI checking Gemfile.lock, you could merge this PR immediately. When you add this repo to s2i-ruby-container repo as submodule, you still have to test it manually in this kind of PR timing.

What I imagined for this repo's CI is

1. Install s2i like s2i-ruby-container 's .travis.yml.
2. Prepare 3 job cases using Travis matrix (jobs) syntax for Ruby 2.5, 2.6, 2.7.
3. Then run the command like the following command or a building command for each job case in the way that is okay to run publicly.

s2i build -e RAILS_ENV=test -r refresh https://github.com/pvalena/rails-ex registry.redhat.io/rhscl/ruby-$v-rhel7 rails-ex-$v

[pvalena]

I get the following with 2.7:

@yselkowitz what command did you run, s2i build? Thanks for checking.

/opt/rh/rh-ruby27/root/usr/share/rubygems/rubygems.rb:275:in `find_spec_for_exe': Could not find 'bundler' (1.16.1) required by your /opt/app-root/src/Gemfile.lock. (Gem::GemNotFoundException)

Yes, this is caused by Ruby 2.7 switching to Bundler 2. Now it requires Gemfile.lock 'conversion'. Bundler 2 didn't bring any backward incompatible changes, but they may diverge further on, so they're not interchangable and thus require conversion.
https://bundler.io/blog/2019/01/03/announcing-bundler-2.html

IOW you can't have same Gemfile.lock for Ruby 2.7 and previous, unless we'll add bundle update --bundler for it's assemble, like it's advised.

[pvalena]

Even when this repo is only used for s2i-ruby-container, the we want to check the modification such as this PR at the PR timing, do not we? Test fast, fail fast. If there was the CI checking Gemfile.lock, you could merge this PR immediately. When you add this repo to s2i-ruby-container repo as submodule, you still have to test it manually in this kind of PR timing.

The change is made once a year at most. Not sure timing plays role at these scales asi it's just an "example" app. AFAIR we have discussed this some time ago with @hhorak and we've concluded it was not worth the effort (we'we opted for simple "sanity" check).

s2i build -e RAILS_ENV=test -r refresh https://github.com/pvalena/rails-ex registry.redhat.io/rhscl/ruby-$v-rhel7 rails-ex-$v

Yes, but you have to also catch the error codes, check if the resulting container runs (the app itself runs and responds).. that's why we have container-common-scripts. So it may work fine, but we lack the time to write the test suite. (It's not a simple install+run.)

[pvalena]

Ok, let's merge this, and resolve Ruby 2.7 support in another PR.