Use chef_data_uploader to put cookbooks in place prior to converge

[test-kitchen]

Use chef_data_uploader to put cookbooks in place prior to converge

[fnichol]

This makes good sense. Initially I was relying on Vagrant and Berkshelf "magic" to handle cookbooks, roles, and data bags for me in Jamie's early days. Once I started writing the bluebox and ec2 drivers then the problem needed to be solved more generally.

Unless you have any bugs or blockers I'd like to circle back to this after test-kitchen/test-kitchen#35 is dealt with. That should speed up the converge action on all drivers and Vagrant should get a speed boost for free at that point.

[fnichol]

Update, I think I'm going to go this way now. If I ask Vagrant for its SSH config (with vagrant ssh-config), then I can make straight up SSH calls to the VM. Seems like the right thing to do 😄

[brugidou]

Do we need to upload using SCP or can't we just use the built-in vagrant chef-solo provisioning which automatically adds shared folders for the cookbook path? This would avoid running SCP every time while testing.

Adding chef.cookbooks_path ["some", "paths"] in the Vagrantfile should be enough

Now the question is how to populate the path correctly ? it seems that the private method "local_cookbooks" from the ChefDataUploader does the job for librarian/berkshelf managed repositories.

[fnichol]

This should be closed out with #12

[fnichol]

@brugidou thanks to @fujin's pull request you can keep the Vagrant/chef-solo provisioning by enabling the follow settings:

---
driver_plugin: vagrant
driver_config:
  use_vagrant_provision: true
  use_vagrant_berkshelf_plugin: true

The primary reason for veering slightly away from the builtin Vagrant approach is that small inconsistencies build up between the vagrant driver and all other drivers. I've even seen some new features propsed via kitchen-vagrant that need re-implementation for the other drivers. Hopefully this will help. Then again, we'll see 😄