Module installation of xDscResourceDesigner failed with exit code at <ScriptBlock> about dscresource.tests HOT 20 CLOSED

I'll mention this again here. I think my PR (dsccommunity/xDSCResourceDesigner#29) may have fixed this if we publish the module (so it can be downloaded from the gallery) I'm not 100% on that is the fix though.

from dscresource.tests.

Fantastic! 👍

from dscresource.tests.

The version of xDSCResourceDesigner with @tysonjhayes' fix has been published on PSGallery (as v1.6.0.0).
@PlagueHO please let us know if you are still seeing this error.
Thanks

from dscresource.tests.

Really hoping that fixes it, I'm getting really tired of that error. 😁

from dscresource.tests.

Fantastic! Thank you! 👍 I'll let you know if I see it again. I'll keep this issue open for a few days until I get a chance to check in some more DSC Resource changes. It happened about 50% of the time so hopefully we'll know if it's resolved fairly quickly. Thanks again.

from dscresource.tests.

It isn't looking good unfortunately :(. The first thing I committed failed:

Is it possible that this is something like a download error/timeout when downloading the resource/module?

from dscresource.tests.

@Dan1el42 added xDscResourceDesigner download logic

from dscresource.tests.

We can simply replace nuget by git clone to clone master (the latest release) version of xDscResourceDesginer for now. Also, getting packages code doesn't belong to pester tests (Meta.Tests.ps1) and should be moved to TestRunner.psm1.

from dscresource.tests.

This issue seems to have stalled but is still giving me a lot of grief (and many many dummy commits :) ). Any objections if I make the changes that @vors has suggested in my fork and if it resolves the issue submit a PR?

from dscresource.tests.

You have my blessing :)

from dscresource.tests.

Awesome! Thank you :)

Re: Moving the package getting code into TestRunner.psm1:
I looked at making this change as well, but it seems none of the DSC resources here are configured to call it to perform unit testing. So, if I moved the package get code over to TestRunner.psm1 then it'll break all the AppVeyor configs for all existing DSC resources I think - which I think is probably a 👎 . So I've left this change for now.

Moving over to Git does seem to have resolved the issue - so that is a great call there. I'll submit the PR tomorrow once I've had a change to put it through a few more builds.

from dscresource.tests.

The only drawback of this approach is that we don't test the released product on PS Gallery, but rather our development code. True, it's coming from master branch and theoretically SHOULD be the same, but... things go wrong.

I think it's OK to do it as a temporary solution, but we should investigate why we were getting that error at the first place.

Also, perhaps we should use PackageManagement for WMF 5 and rely on git clone only for WMF 4 for now...?

from dscresource.tests.

@KarolKaczmarek, you are right. I did do some investigation on this error before switching it over to use Git on my fork and it actually appears that the module is being installed, but nuget.exe is returning a blank exit code (rather than 0) on these occasions.

I could do a bit of testing to confirm if the module is actually being installed or not and see if the blank exit code actually does represent a success or fail. I couldn't find any documentation on blank error codes for Nuget so this could mean that the process is terminating prematurely?

An alternate approach could be to only use the Git method if the Nuget method returns a blank error code.

The problem I see though with using two different sources of this code is that there will always be a small period of time when the Package and the Git source is different and therefore will result in different tests and probably failures.

Is it worth implementing a dev branch on this repo and only clone the master branch when testing?

from dscresource.tests.

Using git method only when nugget returns a blank error code sounds reasonable (just leave a log message we are switching to obtaining ResourceDesigner from git instead of nuget).

Is it worth implementing a dev branch on this repo and only clone the master branch when testing?

Not sure what you mean here? We have dev and master branches already on xDSCResourceDesigner repo.

edit: I see, you are probably referring to adding dev branch for DscResource.Tests repo? Can you clarify how that would help? From what I see the problem with nuget appears when obtaining ResourceDesigner, not DscResource.Tests.

from dscresource.tests.

Thinking about adding a dev branch: You're completely right. Ignore that suggestion. :)

from dscresource.tests.

I think we should address CI scenario first, because people are frustrated by failed breaks on legitimate source changes.
We can even temporarily disable DscResource designer check at all, if needed.
Common test run on all repos doesn't take a long time, so it's easy to re-enable them, once we close on it.

We don't have WMF 5 on worker machines (althought with can get it with os: unstable entry in appveyor.yml), so we cannot use Install-Module cmdlets. That's the reason why there is a direct call to nuget.exe.

@PlagueHO maybe we can just ignore exit code for nuget process? In the worst case, we will get an error message later, but as you observe installation actually happens.

from dscresource.tests.

I think I've found the issue with the call to Nuget and resolved it. It seems that Start-Process is actually causing a problem here because I was still occasionally running into the exact same problem when calling Git.exe (using Start-Process as well) where a blank error code was being returned and nothing was being downloaded. So, I replaced the fancy start-process code with just a plain old & call and then check the $LASTEXITCODE parameter and the problem seems to go away.

I've also switched to using the Nuget-Anycpu.exe that is downloaded with the Get-PackageProvider cmdlet rather than use the Nuget.exe that is automatically available on the AppVeyor servers. This allows the code to work on fresh Windows machines.

And finally, what I've also done is change the code so that rather than use NuGet it will first check for the PowerShellGet module and use that if available (e.g. Install-Module xDSCResourceDesigner). If it the module is not available it'll use the Nuget-AnyCPU.exe call (which now works). If that fails then the Git method will be tried.

Also, the reason why I'm checking for the PowerShellGet Module rather than testing for WMF5 is that MS released PowerShellGet (at least a preview anyway) for WM3 and WMF4 a few weeks back, so it might be available on some servers without WMF5: https://www.microsoft.com/en-us/download/details.aspx?id=49186

I've also moved this code all out into a separate function in the TestHelper module. There is a DownloadUsing parameter that can be passed that will control which download methods to try:
Nuget: Download from Nuget (or PSGet if available) only - if fails will terminate.
Git: Download from Git only - if fails will terminate.
NugetThenGit: Download from Nuget (or PSGet if available), but if fails will try Git.

It defaults to NugetThenGit, but I'm thinking that we could change the default to Nuget now that the problem with Nuget seems to be resolved.

Additional: I was mistaken that the module was still being installed when the Blank exit was returned from Nuget. I actually suspect the process is either terminating or not starting up properly. But given that Git.exe also sometimes behaves this way I think it might be something to do with the Start-Process cmdlet or Process object being returned.

I'll document this in the PR if the above sounds OK.

from dscresource.tests.

@PlagueHO wow, Start-Process usage is a good catch! Still not sure why it happens.

I'm a big fan of keeping simple things simple.
We want a straightforward, consistent tests, that works the same way or fails the same way.
Introducing NugetThenGit and other options would make troubleshooting harder, if we need to look at this code in two months. Adding code which is not used at all doesn't sound right ever.

About out-of-box nuget vs inbox nuget: these tests are mainly for CI.
If there is no inbox nuget, then let Import-Module xDscResourceDesigner fail.
It will provide a good, actionable error message so person who encounter it can use their own pet way to install things. It's certainly not desirable to download and install software to somebodies machine without explicit ask.

I suggest

1. remove options.
2. If it's not appveyor (check for $env:APPVEYOR) skip all install steps and go directly to Import-Module step. If it fails, fine.
3. use built-in nuget for appveyor.

from dscresource.tests.

Good call. I agree, keeping it simple is best. I think now that we've managed to isolate the cause of the problem with the Nuget call it's just better to do away with the download using git.

Also, good idea about the $ENV:AppVeyor check. Have implemented your suggestions and just testing them now. :)

So in summary:

1. If not AppVeyory goto 3
2. If PowerShellGet module available call Install-Module else Install using Nuget.exe
3. Import-Module

from dscresource.tests.

👍

from dscresource.tests.