Closed kevinjpickard closed 7 years ago
It might be an offtopic, but I receive the same message during Azure Automating runbook execution. Azure runs a script on a VM, and what the script does is to import the necessary modules. In Azure logs I see the "Preparing modules for first use" Still no resolution on that issue.
I'm having trouble getting Powershell scripts to run in Windows VMs on GCE. I can run the exact same test suite locally, and everything works fine. I think the only significant differences between these failures and my local environment are the driver (
kitchen-google
) and the images, which are the default Windows Server images from google (2012 R2 and 2016 currently, but will expand to include other versions later, including Desktop variants).I'm not using Chef or other configuration management tools, just serverspec and rspec. Here is the
.kitchen.yml
file I am using for these tests:Note that there are also linux boxes defined, which is why the transport is overridden in the windows platforms.
The powershell scripts I am running are pretty simple, just setting a couple of registry keys each. Here is the general form:
This is obviously not the exact script, and there are a couple different ones that I'm seeing this error with, but they all follow this general format. Unless I am mistaken, I do not believe this is anything fancy, and I believe that these cmdlets are included with vanilla Powershell.
Again, I can also run these tests in local VMs using a second
.kitchen.yml
file, which is:So when I run the tests locally, everything passes and I have no issues. When I push to github and travis kicks off the build (or I override the kitchen file to the one which points to GCE) I get the following message:
This then returns 1, which then is interpreted as a failure, and Test-Kitchen exits. I have tried different image versions as far back as a year ago, but no luck. Google shows me a few suggestions, but not many. Most of these involve
$ProgressPreference = "SilentlyContinue"
and-NoProfile
, but those don't work for me.In the ruby scripts which I use to drive the tests, this is how I'm running the command:
and when I check
exit_status
,1
is returned:In case its useful, here's my
Gemfile.lock
: