Open russellseymour opened 5 years ago
Hey @russellseymour thank you for opening this. We will take a look and see if we can figure out what is going on here.
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.
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?
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.
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
@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
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:When Habitat runs the package, Chocolatey is installed correctly and indeed the
chocolatey_resource
runs, but the following errors are thrown.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):
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