Uh oh!
There was an error while loading. Please reload this page.
[CI] Fix the build on 3.0 - #46
Conversation
Should get things passing on: - ruby-2.5.3 - jruby-9.1.17.0
…a supervision tree" See d9b806a
Makes it easier to ensure that the build stays green from the RSpec 2.99 -> RSpec 3.x transition.
This conversion is done by Transpec 3.4.0 with the following command:
transpec -f
* 65 conversions
from: obj.should
to: expect(obj).to
* 51 conversions
from: == expected
to: eq(expected)
* 8 conversions
from: it { should ... }
to: it { is_expected.to ... }
* 6 conversions
from: obj.should_not
to: expect(obj).not_to
* 5 conversions
from: =~ /pattern/
to: match(/pattern/)
* 5 conversions
from: it { should_not ... }
to: it { is_expected.not_to ... }
* 3 conversions
from: obj.should_receive(:message)
to: expect(obj).to receive(:message)
* 2 conversions
from: be_false
to: be_falsey
* 2 conversions
from: its(:attr) { }
to: describe '#attr' do subject { super().attr }; it { } end
* 1 conversion
from: lambda { }.should
to: expect { }.to
* 1 conversion
from: mock('something')
to: double('something')
* 1 conversion
from: obj.stub(:message)
to: allow(obj).to receive(:message)
* 1 conversion
from: pending
to: skip
For more details: https://github.com/yujinakayama/transpec#supported-conversions...with a documented, supported argument matcher block to #receive. Unsupported in #with: rspec/rspec-mocks#377 (comment) Supported in #receive: https://github.com/rspec/rspec-mocks#arbitrary-handling
Convert specs to RSpec 3.8.2 syntax with Transpec This conversion is done by Transpec 3.4.0 with the following command: transpec -f * 2 conversions from: obj.stub(:message => value) to: allow(obj).to receive_messages(:message => value) For more details: https://github.com/yujinakayama/transpec#supported-conversions
This reverts commit a9d85a5.
sfgeorge
commented
Aug 25, 2019
@bklang@lpradovera@gfaza Can you review this for me? |
bklang
left a comment
There was a problem hiding this comment.
LGTM, other than the question about Cucumber/Ruby 1.9.3
| s.add_development_dependency %q<cucumber>, [">= 0"] | ||
| s.add_development_dependency %q<bundler>, [">= 1.0"] | ||
| s.add_development_dependency %q<rspec>, [">= 3.0"] | ||
| s.add_development_dependency %q<cucumber>, ["< 3.0"] |
There was a problem hiding this comment.
It looks like this was done to make Ruby 1.9.3 happy, but we no longer need to support that ancient version. Should this restriction be lifted?
There was a problem hiding this comment.
@bklang I was thinking about that too (actually, I completed the cuke upgrade locally and confirmed it's a small effort).
Reason for possibly not doing it.. a handful of cucumber features fail unless we fully embrace cucumber >= 3.0n syntax. But since the syntax is not backwards compatible, it means that the same features will have to remain different on support/2.x vs. develop.
I'd lean towards having the two branches have a common denominator, unless it drags down develop in some way.
But I can be swayed - I can update this branch to embrace cuke 3.0 if you like it. What do you think?
There was a problem hiding this comment.
Your answer makes sense to me. There's no urgency to upgrade cucumber, so let's leave it for now. As you say, we can do this work whenever we have a better reason to do it, and in the meantime we benefit from keeping backports simple. 👍
There was a problem hiding this comment.
Meant to reply back earlier... ... thanks man.
Up-port the CI fixes from #45 for RubyAMI 2.4 to 3.0: