Effortless: Using chef client with chocolatey resource fails

[russellseymour]

Description

I am trying to use the Effortless pattern to create a workstation cookbook for my Windows 10 machines. I am using the newly merged chef/scaffolding-chef-infra package which has support for Windows now.

The package only installs Chocolatey and then uses the chocolatey_package resource to install two applications:

1. Visual Studio Code
2. Firefox

When Habitat runs the package, Chocolatey is installed correctly and indeed the chocolatey_resource runs, but the following errors are thrown.

workstation.default hook[init]:(HK):     Failures
workstation.default hook[init]:(HK):      - vscode (exited 1) - vscode not installed. An error occurred during installation:
workstation.default hook[init]:(HK):      Item has already been added. Key in dictionary: 'Path'  Key being added: 'PATH'
workstation.default hook[init]:(HK):     STDERR:
workstation.default hook[init]:(HK):     ---- End output of C:\ProgramData\chocolatey/bin/choco.exe install -y vscode ----
workstation.default hook[init]:(HK):     Ran C:\ProgramData\chocolatey/bin/choco.exe install -y vscode returned 1

Indeed the commands that have failed work correctly when run as is in an elevated PowerShell window:

In case the text in the image is too small to see the error is:

I did think that something strange was happening when chef-client was run in the bundled PowerSHell core, however I have installed PSCore on the machine and run the same commands and no errors are thrown.

I have seen something like this a few years ago when I wrote POSHChef. It was down to the way in which items are deserialised. If you use the built in PowerShell cmdlet ConvertFrom-JSON in which "Path" and "PATH" are both valid elements in JSON this same error will be thrown.

However if the [System.Web.Script.Serialization.JavaScriptSerializer]::DeserializeObject() is used then "Path" and "PATH" can be made to be the same thing, although it will not be merged. (https://github.com/POSHChef/POSHChef/blob/master/functions/Exported/ConvertFrom-JSONtoHashtable.ps1).

If VSCode (or any app) is installed manually then the chocolatey_resource correctly detects that the app is installed.

Chef Version

This is being installed into the package using stuartpreston/chef-client package as is version 14.11.21`.

Platform Version

Windows: 10 1903 Habitat: 0.82.0

Replication

To replicate this issue please download by my repo at https://github.com/russellseymour/effortless and build the habitat package.

Then on a Windows 10 machine (use a local one or one in Azure for example):

• Install Habitat
• Run a service
• Habitat install the built package
• Load the service

After the package has initialised it will run chef-client and the issues will be seen as above.

When I first ran this I was only installing Visual Studio Code so thought that it might be something to do with that package. To test this I added another one and it failed as well (as seen above). To try and fix VSCode I added /DontAddToPath as a paramater option to Chocolatey but this had no effect either.

Stacktrace

Stack trace is in a Gist - https://gist.github.com/russellseymour/55d71343c5d34cd6f891af37886df5ed

[TheLunaticScripter]

Hey @russellseymour thank you for opening this. We will take a look and see if we can figure out what is going on here.

[sam1el]

I've have tried this myself. I get a 50/50 result if I pass the 'refreshenv' command which i believe has more to do with how quickly things run than the an actual failure. That aside, wouldn't this be expected behavior? It's always been my understanding that chef-client wont read env changes on the fly in the same run unless you pass those env variables in the resource blocks that follow explicitly. Even when running chocolatey outside of chef-client, you have to reload powershell or run refreshenv before many of the programs installed by it will run.

[Defilan]

I'm running into this same issue across multiple Hab projects I'm working on. If I have any cookbooks that used the Chocolatey resource, they will always fail unless I convert them to a clunky execute resource. Is there any idea why this might be failing?

[TheLunaticScripter]

We don't know yet why this is happening but we are waiting on a officially built chef-client for Windows so we can do better testing.

[lbergnehr]

Had this error and it was due to us running this through cygwin, which shadows the path variable with its variable named PATH (all caps). Before running the chef client I modified the environment to have the variable named Path again and then it worked!

$path = $env:PATH
remove-item env:PATH
$env:Path = $path

[TheLunaticScripter]

@lbergnehr 🤔 interesting I'll need to think on that one if that is the case then it may be something in the chef-client itself that needs to be changed. cc @robbkidd