[chef] Re: Re: Success Stories for chef-dk on Windows

[Fabien Delpierre < >]

Correction to my earlier response: technically it's not NTFS that's the problem, rather it's a legacy Win32 API that is still omnipresent.

On Wed, Jan 28, 2015 at 9:46 AM, Torben Knerr < " target="_blank"> > wrote:

Hi David,

ChefDK works fairly well on Windows I would say. There are some glitches if you install it to anything other than C:/opscode/chefdk afaik

If you want to keep your system clean and have taken care of the above mentioned issue you might be interested in this:
https://github.com/tknerr/bills-kitchen

Here's an example cookbook repo which runs all kinds of tests (including test-kitchen) in a bundle environment, which works perfectly fine with the ChefDK embedded Ruby (in fact this is part of my acceptance test suite for bills kitchen ;-)):
https://github.com/tknerr/sample-toplevel-cookbook

HTH,
Torben

Am 28.01.2015 15:09 schrieb "David F. Severski" < " target="_blank"> >:

Ohai, all!

Is chef-dk (0.3.5 and 0.3.6) working well for Windows users? I've not been tracking chef-dk as closely as I'd like, so apologies if this is a repeat question.

Since pulling off my stand alone ruby install and running out of the box chef-dk, I've had problems with both foodcritic (runs silently do nothing) and with test-kitchen (converge actions die due to pathnames being too long). I run with a couple different drives (C: for chef-dk, D: for most of my cookbook dev repos, and E: for my sandbox VMs) and suspect this may be the root of Much Evil(tm) for ruby based tools (the heartache I've gone through with Vagrant on this is staggering).

I'd appreciate any thumbs up/down from fellow Windows 7 users that have multiple drives and are using chef-dk. I keep my host OS pretty clean and it's unlikely (though certainly possible) that I've radically tweaked something in a way that doesn't appreciate being tweaked.

David