Fix sanity check specs warnings #2231

benoittgt · 2019-12-16T08:40:36Z

Fix build errors on sanity check specs.

Bundler.with_clean_env is deprecated
Avoid warning with open-ended dependency

WARNING:  open-ended dependency on activesupport (>= 4.2) is not recommended
  if activesupport is semantically versioned, use:
    add_runtime_dependency 'activesupport', '~> 4.2'
WARNING:  open-ended dependency on actionpack (>= 4.2) is not recommended
  if actionpack is semantically versioned, use:
    add_runtime_dependency 'actionpack', '~> 4.2'
WARNING:  open-ended dependency on railties (>= 4.2) is not recommended
  if railties is semantically versioned, use:
    add_runtime_dependency 'railties', '~> 4.2'
WARNING:  See http://guides.rubygems.org/specification-reference/ for help

benoittgt · 2019-12-16T08:49:32Z

It seems there is an issue with the last Bundler. I downgrade to 2.0.2 on my machine and I don't have the error anymore.

benoittgt · 2019-12-16T14:03:32Z

Related issue for bundler rubygems/bundler#7487

benoittgt · 2019-12-16T14:40:30Z

Sorry for the noise. I will look at JRuby errors.

pirj · 2019-12-17T00:13:09Z

Just a heads-up regarding Overwrite the executable? [yN] No output has been received in the last 10m0s - will try to fix it here #2234

benoittgt · 2019-12-17T08:59:24Z

@pirj I don't think we need to change this part anymore. We still have this kind of noise.

Verify required rspec dependencies
WARNING:  pessimistic dependency on rake (~> 10.0.0, development) may be overly strict
  if rake is semantically versioned, use:
    add_development_dependency 'rake', '~> 10.0', '>= 10.0.0'
WARNING:  pessimistic dependency on thread_order (~> 1.1.0, development) may be overly strict
  if thread_order is semantically versioned, use:
    add_development_dependency 'thread_order', '~> 1.1', '>= 1.1.0'
WARNING:  See http://guides.rubygems.org/specification-reference/ for help
WARNING:  pessimistic dependency on rake (~> 10.0.0, development) may be overly strict
  if rake is semantically versioned, use:
    add_development_dependency 'rake', '~> 10.0', '>= 10.0.0'
WARNING:  pessimistic dependency on cucumber (~> 1.3.15, development) may be overly strict
  if cucumber is semantically versioned, use:
    add_development_dependency 'cucumber', '~> 1.3', '>= 1.3.15'
WARNING:  See http://guides.rubygems.org/specification-reference/ for help
WARNING:  pessimistic dependency on rake (~> 10.0.0, development) may be overly strict
  if rake is semantically versioned, use:
    add_development_dependency 'rake', '~> 10.0', '>= 10.0.0'
WARNING:  See http://guides.rubygems.org/specification-reference/ for help
WARNING:  See http://guides.rubygems.org/specification-reference/ for help
WARNING:  pessimistic dependency on rake (~> 10.0.0, development) may be overly strict
  if rake is semantically versioned, use:
    add_development_dependency 'rake', '~> 10.0', '>= 10.0.0'
WARNING:  pessimistic dependency on thread_order (~> 1.1.0, development) may be overly strict
  if thread_order is semantically versioned, use:
    add_development_dependency 'thread_order', '~> 1.1', '>= 1.1.0'
WARNING:  See http://guides.rubygems.org/specification-reference/ for help
WARNING:  See http://guides.rubygems.org/specification-reference/ for help
WARNING:  pessimistic dependency on rake (~> 10.0.0, development) may be overly strict
  if rake is semantically versioned, use:
    add_development_dependency 'rake', '~> 10.0', '>= 10.0.0'
WARNING:  See http://guides.rubygems.org/specification-reference/ for help
WARNING:  pessimistic dependency on rake (~> 10.0.0, development) may be overly strict
  if rake is semantically versioned, use:
    add_development_dependency 'rake', '~> 10.0', '>= 10.0.0'
WARNING:  pessimistic dependency on cucumber (~> 1.3.15, development) may be overly strict
  if cucumber is semantically versioned, use:
    add_development_dependency 'cucumber', '~> 1.3', '>= 1.3.15'
WARNING:  See http://guides.rubygems.org/specification-reference/ for help
  passes when libraries are required (FAILED - 1)

Failures:

  1) Verify required rspec dependencies passes when libraries are required
     Failure/Error: expect(`bundle exec #{script} 2>&1`).to be_empty
       expected `"WARNING:  pessimistic dependency on rake (~> 10.0.0, development) may be overly strict\n  if rake is...'~> 1.3', '>= 1.3.15'\nWARNING:  See http://guides.rubygems.org/specification-reference/ for help\n".empty?` to return true, got false

With

--- a/spec/sanity_check_spec.rb
+++ b/spec/sanity_check_spec.rb
@@ -47,6 +47,7 @@ RSpec.describe "Verify required rspec dependencies" do
     FileUtils.chmod 0777, script

     bundler_env do
+      puts `bundle exec #{script} 2>&1`
       expect(`bundle exec #{script} 2>&1`).to be_empty
       expect($?.exitstatus).to eq(0)
     end

But where are those dependencies? It seems this noise come from other gemspec of dependencies of gems we install. If think we should rewrite this test.

pirj · 2019-12-17T09:14:12Z

@benoittgt I meant that some Travis build jobs get stuck and fail with timeout while trying to read user input from console on build setup stage. It currently fails on 2.6.3 and 2.3.8 builds. I'll debug it later today.

spec/sanity_check_spec.rb

script/custom_build_functions.sh

JonRowe · 2019-12-18T14:03:43Z

script/custom_build_functions.sh

@@ -1,6 +1,6 @@
 function run_cukes {
  if is_mri_192_plus; then
-    bin/rake acceptance --trace
+    (unset RUBYOPT; bin/rake acceptance --trace)


Ok I see why that was recommended in the bundler thread, this becomes a question of do we want to keep disabling rubygems on rspec-rails, I mean if rails depends on bundler, and bundler depends on rubygems...

Do we now need to add require rubygems instead?

I believe it's required by default unless you set --disable=gems in RUBYOPT.

do we want to keep disabling rubygems on rspec-rails

I don't think we have to. But this is a change we have to address on rspec-dev.
I tried to readd only rubygems as an option but I get warnings. unset seems to be a good option.

This is the only build we have an issue with so it doesn't need to be propagated.

Avoid: Failures: 1) Verify required rspec dependencies passes when libraries are required Got 1 failure and 1 other error: 1.1) Failure/Error: expect(`bundle exec #{script} 2>&1`).to be_empty expected `"WARNING: open-ended dependency on activesupport (>= 4.2) is not recommended\n if activesupport is ... 'railties', '~> 4.2'\nWARNING: See http://guides.rubygems.org/specification-reference/ for help\n".empty?` to return true, got false

On Bundler 2.1.0 the loading of rubygems has been rewritten. It breaks our existing usage of command execution. The --disable=gem flag is problematic because we need to load rubygems in Bundler. It is not explicitly loaded in Bundle 2.1.0 Related: - rubygems/bundler#7487

JonRowe · 2019-12-18T14:04:51Z

I cherry-picked my suggested version of this to another PR, #2240 and merged it because I'm working on fixing the other builds, but I think this is getting closer to fixing rails too.

benoittgt · 2019-12-18T15:33:10Z

This is so broken.

Installing RubyGems 3.1.1
  Successfully built RubyGem
  Name: bundler
  Version: 2.1.0
  File: bundler-2.1.0.gem
ERROR:  While executing gem ... (Gem::InstallError)
    "bundle" from bundler conflicts with /home/travis/.rvm/rubies/ruby-2.6.3/bin/bundle

🤦🏼‍♂️

We have the again the issue where it seems we have bundler 2.1.0 and bundler 2.1.1 installed and the default bundler is 2.1.0?
I am not able to reproduce this error locally.

** Execute cucumber

/home/travis/.rvm/rubies/ruby-2.6.3/bin/ruby -S bundle exec cucumber --tag ~@rails_pre_5.1 --tag ~@rails_pre_5 --tag ~@rails_post_6

(....)

+/home/travis/.rvm/gems/ruby-2.6.3/gems/bundler-2.1.1/lib/bundler/runtime.rb:312:in `check_for_activated_spec!': You have already activated bundler 2.1.0, but your Gemfile requires bundler 2.1.1. Since bundler is a default gem, you can either remove your dependency on it or try updating to a newer version of bundler that supports bundler as a default gem. (Gem::LoadError)

Locally I have:

$ gem list | grep '^bundler ('                                                                           
bundler (2.1.1, 2.1.0, 2.0.2)
$ bundle exec rake cucumber   
/Users/bti/.rvm/rubies/ruby-2.6.3/bin/ruby -S bundle exec cucumber --tag ~@rails_pre_5.1 --tag ~@rails_pre_5 --tag ~@rails_pre_6

Using the default profile...
................... (no errors)

benoittgt · 2019-12-18T15:45:25Z

It's worst than before.

Good output:

Fetching bundler-2.1.1.gem
Successfully installed bundler-2.1.1 as a default gem
Done installing documentation for bundler after 0 seconds
1 gem installed
Current bundler versions installed after 'gem install bundler': bundler (default: 2.1.1, default: 2.1.0)

But after

$ bundle install --binstubs --path ../bundle --retry=3 --jobs=3
Traceback (most recent call last):
	1: from /home/travis/.rvm/gems/ruby-2.6.3/bin/bundle:23:in `<main>'
/home/travis/.rvm/gems/ruby-2.6.3/bin/bundle:23:in `load': cannot load such file -- /home/travis/.rvm/rubies/ruby-2.6.3/lib/ruby/gems/2.6.0/gems/bundler-2.1.1/exe/bundle (LoadError)

The command "eval bundle install --binstubs --path ../bundle --retry=3 --jobs=3 " failed. Retrying, 2 of 3.

I have to move and could not probably look at it today, but tomorrow. Feel free to remove my commits.

This reverts commit be5a2c5.

pirj · 2019-12-18T20:10:32Z

Hey @mvz, can you please take a look?

We're experiencing a weird issue:

You have already activated bundler 2.1.0, but your Gemfile requires bundler 2.1.1. Since bundler is a default gem, you can either remove your dependency on it or try updating to a newer version of bundler that supports bundler as a default gem. (Gem::LoadError)
from /home/travis/.rvm/gems/ruby-2.6.3/gems/bundler-2.1.1/lib/bundler/runtime.rb:31:in `block in setup'
from /home/travis/.rvm/gems/ruby-2.6.3/gems/bundler-2.1.1/lib/bundler/spec_set.rb:147:in `each'
from /home/travis/.rvm/gems/ruby-2.6.3/gems/bundler-2.1.1/lib/bundler/spec_set.rb:147:in `each'
from /home/travis/.rvm/gems/ruby-2.6.3/gems/bundler-2.1.1/lib/bundler/runtime.rb:26:in `map'
from /home/travis/.rvm/gems/ruby-2.6.3/gems/bundler-2.1.1/lib/bundler/runtime.rb:26:in `setup'
from /home/travis/.rvm/gems/ruby-2.6.3/gems/bundler-2.1.1/lib/bundler.rb:149:in `setup'
from /home/travis/.rvm/gems/ruby-2.6.3/gems/bundler-2.1.1/lib/bundler/setup.rb:20:in `block in <top (required)>'
from /home/travis/.rvm/gems/ruby-2.6.3/gems/bundler-2.1.1/lib/bundler/ui/shell.rb:136:in `with_level'
from /home/travis/.rvm/gems/ruby-2.6.3/gems/bundler-2.1.1/lib/bundler/ui/shell.rb:88:in `silence'
from /home/travis/.rvm/gems/ruby-2.6.3/gems/bundler-2.1.1/lib/bundler/setup.rb:20:in `<top (required)>'
from /home/travis/.rvm/rubies/ruby-2.6.3/lib/ruby/site_ruby/2.6.0/rubygems/core_ext/kernel_require.rb:92:in `require'
from /home/travis/.rvm/rubies/ruby-2.6.3/lib/ruby/site_ruby/2.6.0/rubygems/core_ext/kernel_require.rb:92:in `require'
from /home/travis/build/rspec/rspec-rails/tmp/aruba/bin/rspec:27:in `<main>'

After reverting aruba update commit, this problem disappears.

mvz · 2019-12-18T22:04:31Z

That is strange. @pirj any idea how to reproduce this locally?

mvz · 2019-12-18T22:32:04Z

I think what happens is that bundler now sets more env vars than aruba knows to unset. I'll be trying out some fixes in #2241.

pirj · 2019-12-18T22:47:42Z

Thanks for the quick response!

It was introduced to avoid build failure on 2.4 suggesting to update json gem. Let's see if it comes up again.

benoittgt · 2019-12-19T19:51:02Z

@mvz Jon asked the question about ENV vars but without clear answer rubygems/bundler#7487 (comment)

I am trying at the moment to look at difference between 2.0 and 2.1 but the diff is big. rubygems/bundler@2-0-stable...2-1-stable

benoittgt · 2019-12-19T20:05:54Z

Congrats @pirj that's much better!

Edit: I am trying to reproduce locally.
Edit 2: Error on jruby seems related to all commands linked to gem. rubygems/rubygems#2984 (comment)

With Rubygems 3.1 we see on JRuby warnings on every gem commands like: ``` NOTE: Gem::Specification#rubyforge_project= is deprecated with no replacement. It will be removed on or after 2019-12-01. Gem::Specification#rubyforge_project= called from /Users/bti/.rvm/rubies/jruby-head/lib/ruby/gems/shared/specifications/default/json-2.2.0-java.gemspec:18. ``` As a temporary fix we downgrade to 3.0.6, waiting for a json dependency updated. Related: - rubygems/rubygems#2798 - rubygems/rubygems#2984 (comment)

mvz · 2019-12-19T21:52:22Z

@pirj it seems the latest commit in #2241 (c024004) fixed the bundler version problem. I can make a pull request on master for that or you can cherry pick it here.

I'll probably pull that change into Aruba proper as well to improve its unset_bundler_env_vars implementation.

duckinator · 2019-12-20T05:06:47Z

Edit 2: Error on jruby seems related to all commands linked to gem.

If you're able to update the JSON gem to 2.3.0, it should resolve that problem. They stopped using the deprecated rubyforge_project attribute in their gemspec with that version, and that's the source of the warning.

benoittgt · 2019-12-20T12:27:48Z

@duckinator but even if I update json gem and set JSON gem 2.3.0 as default. I still have the warning.

benoittgt · 2019-12-20T13:08:04Z

Closing, in favor of #2244

JonRowe · 2019-12-20T13:09:48Z

Thanks for all your work here @pirj @benoittgt and @mvz I tried to cherry-pick your commits for #2244 where possible, I just wanted the minimal changes to fix the build.

benoittgt · 2019-12-20T13:48:47Z

I am happy with the final result. I think we should open a new discussion on how the build is written. I would love to be able to more easily run the build locally, and run each step without looking at shell functions or Rakefile. Like simply copy paste one line from travis logs.

JonRowe · 2019-12-20T14:04:42Z

@benoittgt more than happy for you to look at that :)

benoittgt changed the title ~~Fix sanity check dep~~ Fix sanity check specs warnings Dec 16, 2019

benoittgt mentioned this pull request Dec 16, 2019

Favor request specs over controller specs when generating a controller #2222

Merged

benoittgt force-pushed the fix-sanity-check-dep branch 6 times, most recently from 62749f3 to a5e0e26 Compare December 16, 2019 13:17

benoittgt force-pushed the fix-sanity-check-dep branch 2 times, most recently from 5adc963 to ff2929f Compare December 16, 2019 14:40

JonRowe reviewed Dec 17, 2019

View reviewed changes

spec/sanity_check_spec.rb Outdated Show resolved Hide resolved

spec/sanity_check_spec.rb Outdated Show resolved Hide resolved

spec/sanity_check_spec.rb Outdated Show resolved Hide resolved

script/custom_build_functions.sh Outdated Show resolved Hide resolved

pirj mentioned this pull request Dec 17, 2019

Work around RubyGems TTY detection #2234

Merged

This comment has been minimized.

Sign in to view

JonRowe mentioned this pull request Dec 18, 2019

Avoid deprecation warning with Bundler.with_clean_env #2240

Merged

pirj force-pushed the fix-sanity-check-dep branch 2 times, most recently from f441a34 to aeb5cf2 Compare December 18, 2019 14:02

JonRowe reviewed Dec 18, 2019

View reviewed changes

benoittgt added 2 commits December 18, 2019 17:04

pirj force-pushed the fix-sanity-check-dep branch from aeb5cf2 to 0007e19 Compare December 18, 2019 14:04

try! Remove bundlers before installing a new one

9c13baf

pirj force-pushed the fix-sanity-check-dep branch from d246c82 to 9c13baf Compare December 18, 2019 14:57

Try to make bundle 2.1.1 default gem version

fc124e9

Pitiful attempts to fix bundler

02a7a6b

pirj force-pushed the fix-sanity-check-dep branch from 4ec4160 to 02a7a6b Compare December 18, 2019 19:40

Revert "Update Aruba to version 0.14.12"

39be63a

This reverts commit be5a2c5.

Address bundler warnings

18e15b1

pirj force-pushed the fix-sanity-check-dep branch from d1f8e95 to 18e15b1 Compare December 18, 2019 21:57

mvz mentioned this pull request Dec 18, 2019

Fix sanity check dep mvz #2241

Closed

pirj added 2 commits December 19, 2019 21:45

Revert some of the changes

6faafbe

Drop json dep

286f84a

It was introduced to avoid build failure on 2.4 suggesting to update json gem. Let's see if it comes up again.

benoittgt closed this Dec 20, 2019

benoittgt deleted the fix-sanity-check-dep branch December 20, 2019 13:08

benoittgt mentioned this pull request Dec 22, 2019

Make build script more readable rspec/rspec-dev#227

Open

Uh oh!

Fix sanity check specs warnings #2231

Fix sanity check specs warnings #2231

Uh oh!

Conversation

benoittgt commented Dec 16, 2019

Uh oh!

benoittgt commented Dec 16, 2019

Uh oh!

benoittgt commented Dec 16, 2019

Uh oh!

benoittgt commented Dec 16, 2019

Uh oh!

pirj commented Dec 17, 2019

Uh oh!

benoittgt commented Dec 17, 2019

Uh oh!

pirj commented Dec 17, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

JonRowe Dec 18, 2019

Choose a reason for hiding this comment

Uh oh!

JonRowe Dec 18, 2019

Choose a reason for hiding this comment

Uh oh!

pirj Dec 18, 2019

Choose a reason for hiding this comment

Uh oh!

benoittgt Dec 18, 2019

Choose a reason for hiding this comment

Uh oh!

JonRowe Dec 19, 2019

Choose a reason for hiding this comment

Uh oh!

JonRowe commented Dec 18, 2019

Uh oh!

benoittgt commented Dec 18, 2019

Uh oh!

benoittgt commented Dec 18, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pirj commented Dec 18, 2019

Uh oh!

mvz commented Dec 18, 2019

Uh oh!

mvz commented Dec 18, 2019

Uh oh!

pirj commented Dec 18, 2019

Uh oh!

benoittgt commented Dec 19, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

benoittgt commented Dec 19, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mvz commented Dec 19, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

duckinator commented Dec 20, 2019

Uh oh!

benoittgt commented Dec 20, 2019

Uh oh!

benoittgt commented Dec 20, 2019

Uh oh!

JonRowe commented Dec 20, 2019

Uh oh!

benoittgt commented Dec 20, 2019

Uh oh!

JonRowe commented Dec 20, 2019

Uh oh!

Uh oh!

pirj commented Dec 17, 2019 •

edited

Loading

benoittgt commented Dec 18, 2019 •

edited

Loading

benoittgt commented Dec 19, 2019 •

edited

Loading

benoittgt commented Dec 19, 2019 •

edited

Loading

mvz commented Dec 19, 2019 •

edited

Loading