Add Microsoft.Windows.Assertion Module

[Trenly]

• I have signed the Contributor License Agreement.
• This pull request is related to an issue.

Premise

Until DSC v3 is released, there isn't a good way to assert specific system parameters in DSC - Especially for use with WinGet. This module adds several different DSC Resources that can be used for asserting the state of a system, primarily for use in WinGet configuration files. This will allow DSC users in enterprises to target specific architectures, specific domain roles, computers with specific print servers, etc. by adding these assertions directly into their configuration YAML instead of having to push out a wrapper script that performs the checks before invoking the DSC, and without having to write their own implementations using the Script DSCResource.

---

[Trenly]

Didn't realize I still have scriptanalyzer errors

[ryfu-msft]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Trenly]

Hmmmmmm

[Trenly]

@ryfu-msft - I'm a bit stuck here and don't know how to go about it. When I run the pester tests locally, I see them pass -

PS E:\winget-dsc> Invoke-Pester E:\winget-dsc\tests\Microsoft.Windows.Assertion

Starting discovery in 1 files.
Discovery found 73 tests in 711ms.
Running tests.
[+] E:\winget-dsc\tests\Microsoft.Windows.Assertion\Microsoft.Windows.Assertion.Tests.ps1 5.3s (3.8s|814ms)
Tests completed in 5.33s
Tests Passed: 73, Failed: 0, Skipped: 0, Inconclusive: 0, NotRun: 0
PS E:\winget-dsc> $env:COMPUTERNAME
CORSAIR-JLU545

I even went to a completely different computer, checked out the repo, and ran the tests, where they all passed.

PS C:\git\winget-dsc> Invoke-Pester C:\git\winget-dsc\tests\Microsoft.Windows.Assertion

Starting discovery in 1 files.
Discovery found 73 tests in 510ms.
Running tests.
[+] C:\git\winget-dsc\tests\Microsoft.Windows.Assertion\Microsoft.Windows.Assertion.Tests.ps1 17.3s (16.44s|347ms)      
Tests completed in 17.3s
Tests Passed: 73, Failed: 0, Skipped: 0, Inconclusive: 0, NotRun: 0
PS C:\git\winget-dsc> $env:COMPUTERNAME
M5423133

Then, I used Invoke-DSCResource to manually test, and everything passed there; Granted I did have to use valid PnPDevices that were on my system for the cases where I expected it to match, but all of the ones that I expected to not match didn't match.

As a final effort, I opened up a new Windows Sandbox, mapped in the folder from Git, installed PowerShell 7, and tried running the tests. They all passed again -

PS C:\Users\WDAGUtilityAccount> Invoke-Pester C:\Users\WDAGUtilityAccount\Desktop\winget-dsc\tests\Microsoft.Windows.Assertion\

Starting discovery in 1 files.
Discovery found 73 tests in 715ms.
Running tests.
[+] C:\Users\WDAGUtilityAccount\Desktop\winget-dsc\tests\Microsoft.Windows.Assertion\Microsoft.Windows.Assertion.Tests.ps1 11.71s (10.33s|699ms)
Tests completed in 11.73s
Tests Passed: 73, Failed: 0, Skipped: 0, Inconclusive: 0, NotRun: 0
PS C:\Users\WDAGUtilityAccount> $env:COMPUTERNAME
C1BE12D1-33D2-4

Can you help me understand why the pipelines are showing different results? Are they using a specific version of Pester?

[ryfu-msft]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Gijsreyn]

Trenly, maybe this helps:

You can run it through Azure Pipelines itself. I had a similar problem, but this was related to a PowerShell module not being available on the hosted agents (see #120). If you want, you can always hit me up to give it a try. Cheers.

[Trenly]

Trenly, maybe this helps:

Are you saying that the module for Get-PNPDevice isn't present? Because it seems to me the only reason it's failing is because the mocks are not applying. If the mocks were applying, you wouldn't see the CIM error

[Gijsreyn]

Trenly, maybe this helps:

Are you saying that the module for Get-PNPDevice isn't present? Because it seems to me the only reason it's failing is because the mocks are not applying. If the mocks were applying, you wouldn't see the CIM error

No, that's not actually what I was referring to. What I wanted to refer to is that I made an assumption that you hadn't tried running the test on an Azure Pipelines hosted agent. I have seen some strange cases now where some things are available on your local machine (or sandbox) but slightly behave differently on the hosted agents. That's why I wanted to run it through the agent itself and see what it was doing. The pipeline running in this repository doesn't always output the verbosity message you might have sought. And I think the Get-PnPDevice was there; otherwise, the other tests would have also failed.

P.S. The tests were run under Pester v5.6.1.

[Gijsreyn]

Nit: Should be Microsoft.WinGet.Assertion