I like test-kitchen but it doesn’t seem to fit well with the use case of a
VM that should stick around for awhile.
I do all my development work in VMs, so we have a cookbook that will spin
up a full dev environment (install a desktop manager, install intellij,
etc). With this VM I use
vagrant up and
vagrant provision and
vagrant halt all the time and it seems to fit well with this use case.
It seems like test-kitchen wasn’t meant to be used for VMs that stick
around, everything is geared towards the VM being destroyed at the end of a
run. Sure you can run the vagrant commands on the generated vagrantfile but
it feels kinda janky.
Maybe my perception needs some adjustment but I thought I should share it
On Mon, May 4, 2015 at 10:06 AM, Lamont Granquist firstname.lastname@example.org wrote:
Generally test-kitchen is a better approach than using vagrant-berkshelf
and vagrant-omnibus. The latter two are somewhat deprecated and are mostly
falling behind test-kitchen’s features.
On 05/02/2015 06:23 PM, Christopher Hahn wrote:
Pardon the chaff….I am pretty sure that feeding the —debug flag to
my build.gradle exec block, will tell me what I need to know.
On May 2, 2015, at 6:00 PM, Christopher Hahn email@example.com
I managed to take from the small README that this plugin has on github
that it helps
vagrant sync a berkshelf on the Node so that it can then launch chef-solo
to provision it.
I would love to find a bit more documentation was to just what it is
doing during vagrant actions
i.e. what precisely happens between: and the:
17:54:27.468 [INFO] [org.gradle.process.internal.DefaultExecHandle]
Starting process ‘command ‘/usr/bin/vagrant’’. Working directory:
Command: /usr/bin/vagrant provision cdsdashboard
I am certain that I am needing to be directed elsewhere…this is just
where I know to start.
P.S. I did add a comment/question on the hub as well.