scalefactory / vagrant-cucumber Goto Github PK

We use a Ruby globals to handle vagrant-cucumber's debug mode across a few contexts.

We should instead use a settings class, instantiated as a singleton to handle vagrant-cucumber's global settings.

The hacking instructions in #5 should ideally show me how to test the code so you can merge in my contribution knowing I haven't fucked anything up.

Even if this just has some manual steps and then tells you to run the examples, I think that's fine.

Tried using Docker as a vagrant provider.
It breaks on:

    Given there is a running VM called "vm1"                         # vagrant-cucumber-0.0.8/lib/vagrant-cucumber/step_definitions.rb:3
      Rolling back VM states
      undefined method `has_snapshot?' for #<VagrantPlugins::DockerProvider::Driver:0x00000001eded00> (NoMethodError)
      features/process.feature:8:in `Given there is a running VM called "vm1"'
    Then there should not be a process called "i-dont-exist" running # features/step_definitions/process.rb:12
      Vagrant attempted to call the action 'snapshot_rollback' on the provider
      'Docker (0ba23f6d0ad2f4164a3345226d014214bc0c0a55ba5780f6819fad0dc6c0836e)', but this provider doesn't support this action. This
      is probably a bug in either the provider or the plugin calling this
      action, and should be reported. (Vagrant::Errors::UnimplementedProviderAction)
      /opt/vagrant/embedded/gems/gems/vagrant-1.6.5/lib/vagrant/machine.rb:168:in `block in action'
      /opt/vagrant/embedded/gems/gems/vagrant-1.6.5/lib/vagrant/environment.rb:474:in `lock'
      /opt/vagrant/embedded/gems/gems/vagrant-1.6.5/lib/vagrant/machine.rb:161:in `call'
      /opt/vagrant/embedded/gems/gems/vagrant-1.6.5/lib/vagrant/machine.rb:161:in `action'
      /home/erik/.vagrant.d/gems/gems/vagrant-multiprovider-snap-0.0.14/lib/vagrant-multiprovider-snap/command/rollback.rb:31:in `block in execute'
      /opt/vagrant/embedded/gems/gems/vagrant-1.6.5/lib/vagrant/plugin/v2/command.rb:226:in `block in with_target_vms'
      /opt/vagrant/embedded/gems/gems/vagrant-1.6.5/lib/vagrant/plugin/v2/command.rb:220:in `each'
      /opt/vagrant/embedded/gems/gems/vagrant-1.6.5/lib/vagrant/plugin/v2/command.rb:220:in `with_target_vms'
      /home/erik/.vagrant.d/gems/gems/vagrant-multiprovider-snap-0.0.14/lib/vagrant-multiprovider-snap/command/rollback.rb:29:in `execute'
      /home/erik/.vagrant.d/gems/gems/vagrant-multiprovider-snap-0.0.14/lib/vagrant-multiprovider-snap/command/root.rb:50:in `execute'
      /opt/vagrant/embedded/gems/gems/vagrant-1.6.5/lib/vagrant/cli.rb:42:in `execute'
      /opt/vagrant/embedded/gems/gems/vagrant-1.6.5/lib/vagrant/environment.rb:292:in `cli'
      /home/erik/.vagrant.d/gems/gems/vagrant-cucumber-0.0.8/lib/vagrant-cucumber/step_definitions.rb:83:in `After'

Not sure if a Docker provider makes sense for vagrant-cucumber, but I am looking for something more efficient than Virtualbox or VMWare.

If I wanted to submit a pull request, I would like a CONTRIBUTING.md file to tell me how you like things done.

The step def for running a shell command is quite long and gnarly, and you're using instance variables (e.g. @last_shell_command_output) to pass state to the subsequent step defs.

I would push this code down into the glue layer, maybe just make a method on that module like execute_on(machine, command) and have that wrap all the detail. You can then expose last_shell_command_output as another method / attribute on the glue module.

This will keep the step defs simpler and allow you to change the implementation of the glue layer without breaking the step defs.

Make it easier to test and release this gem by adding Travis configs.

[vm1] translation missing: en.vagrant_snap.actions.vm.snapshot_take.taking

Idiomatic use of Cucumber is to use Given to set up context, When to carry out an action, and Then to inspect the state of the system after that action has happened in that context.

Cucumber doesn't care about which keyword you use in practice, but it helps for readability if the action that changes the state of the system is labelled with When.

I notice that the step def for running a shell command is a Then step. I would use a When step for this. In Aruba, we use a phrase like this:

When I successfully run `ls -la`

or just

When I run `ls -la`

And we then have other steps to check the output / exit status.

We're seeing an old issue re-surface where the output for the cucumber run is delayed ... in these instances, it turns out that cucumber version 2.0.0 has been installed into ~/.vagrant.d/gems/gems .. not sure exactly why the formatter fails, haven't dug into it yet, but it may be prudent to pin the version in the gemspec to < 2.0.0 for now until we can fully support cucumber > 2.0.0

Thanks for great tool, is there any word or time frame to support the vagrant-aws plugin?

Is the issue holding support back the ability to do snapshots and rollback? If so, I would be happy to have a feature to support running on AWS without the snaps....

Thanks again :)