Repository navigation
Assertion section in config doc #1421
Description
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
Activity
denelon commentedon Mar 5, 2026
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 commentedon Mar 12, 2026
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.