This conversion is done by Transpec 3.2.2 with the following command:
transpec -f
* 17 conversions
from: it { should ... }
to: it { is_expected.to ... }
* 8 conversions
from: obj.should_receive(:message)
to: expect(obj).to receive(:message)
* 4 conversions
from: it { should_not ... }
to: it { is_expected.not_to ... }
* 3 conversions
from: obj.stub(:message)
to: allow(obj).to receive(:message)
* 1 conversion
from: be_false
to: be_falsey
* 1 conversion
from: be_true
to: be_truthy
For more details: https://github.com/yujinakayama/transpec#supported-conversions
This commit also includes a number of errorcases from the CLI side of things,
but doesn't actually include much error handling inside of the business logic.
Fixes#2
That is, unless you say 'y' or you --force it. Tested the interactive query
part outside of Aruba since it's a PITA to make it work with Thor and
Aruba::InProcess. Verified on an actual machine though:
ubuntu@ip-10-226-175-124:~$ jpm update
A version of the repo is already on disk, overwrite? [y, n] n
ubuntu@ip-10-226-175-124:~$ sudo jpm update
A version of the repo is already on disk, overwrite? [y, n] y
Fetching <http://updates.jenkins-ci.org/update-center.json> ...
Wrote to /var/lib/jenkins/update-center.json
ubuntu@ip-10-226-175-124:~$
On a real machine I found this stupid exception:
ubuntu@ip-10-226-175-124:/vagrant/pkg$ jpm list
/var/lib/gems/1.8/gems/jpm-1.0.0/lib/jpm.rb:32:in `has_plugins?': undefined method `<=' for #<Array:0x7fbb402b3240> (NoMethodError)
from /var/lib/gems/1.8/gems/jpm-1.0.0/lib/jpm/cli.rb:11:in `list'
from /var/lib/gems/1.8/gems/thor-0.19.0/lib/thor/command.rb:27:in `__send__'
from /var/lib/gems/1.8/gems/thor-0.19.0/lib/thor/command.rb:27:in `run'
from /var/lib/gems/1.8/gems/thor-0.19.0/lib/thor/invocation.rb:126:in `invoke_command'
from /var/lib/gems/1.8/gems/thor-0.19.0/lib/thor.rb:359:in `dispatch'
from /var/lib/gems/1.8/gems/thor-0.19.0/lib/thor/base.rb:440:in `start'
from /var/lib/gems/1.8/gems/jpm-1.0.0/bin/jpm:14
from /usr/local/bin/jpm:19:in `load'
from /usr/local/bin/jpm:19
The Plugin class will encapsulate the meta-data for a single plugin record from
the udpate-center, while catalog is intended to be the primary mapping of the
update-center file as a whole.
I'm not sure yet if the Catalog class should be resolving the plugins on disk
and what's available
This commit includes some code to rnu the `jpm` CLI in the same Ruby process,
which will allow us to mock things out properly instead of creating a fake
JENKINS_HOME on the file system, yay
R. Tyler Croy
Joshua Hoblitt