Assertion section in config doc

[SteveL-MSFT]

Summary of the new feature / enhancement

Admins may want to blast out configurations and have it only apply if the config is applicable via assertions. Having it as a dedicated section in the config makes it easy to understand what is being tested and you don't have to declare dependsOn for it as it would always be run first. In this case, if any assertion fails it would stop deployment immediately. One question is whether we need to assert(false) instead of always assuming assert(true).

Proposed technical implementation details (optional)

# assertions would always be processed first
# all asserts must be true otherwise an error is returned
# collect and return all assertions and don't fail on first false
assertions:
  resources:
    - type: Microsoft/OSInfo
      properties:
        family: Windows
    - type: Foo/Bar
      properties:
        hello: world
resources:
  - type: Microsoft.Windows/Registry
    properties:
      keyPath: HKCU/Environment
      _exist: true

[denelon]

WinGet already has an "assert" section as a top-level concept in the 0.2 WinGet Configuration schema.

The intent is "don't run this configuration if the device isn't in the proper starting state".

One complexity is when we leverage composition to logically assemble a single configuration document to perform a complete configuration from a set of multiple configuration documents.

In the case where multiple documents are consolidated, all assertions should be executed first prior to any "set" operations.

I wouldn't want a scenario where a partial configuration is run and then fails "somewhere in the middle" due to a late assertion failure.

[SteveL-MSFT]

WG discussed this, the initial post example was updated to reflect what was discussed. Assert(false) may be considered for the future, but no need to support it initially.