Closed mgreenegit closed 5 months ago
@mgreenegit, not sure I follow this issue - do you mean that if a resource instance defines _inDesiredState
in the configuration, it should be checked directly somehow? Can you show a concrete example or help me understand better?
Right now the contract for test
is that either:
test
operation. dsc
calls get
for the resource and performs a synthetic comparison between the desired state in the configuration document and the actual state returned by the resource.test
. dsc
calls test
for the resource and the resource returns a JSON object representing the actual state of the resource and the _inDesiredState
property as true
if the resource is in the desired state or false
if it isn't. Optionally, the resource may also return the differing properties as an array. If the resource doesn't return the list of differing properties, DSC calculates it.It's worth noting that _inDesiredState
should only be a property for resources that implement test
- and, when they do, the property must use the well-known schema implementation. The schema for _inDesiredState
is:
{
"type": ["boolean", "null"],
"readOnly": true
}
It's a read-only property, it can't be sent to the resource, only returned by it. Contractually, it should only be returned as a boolean value for the test
operation. For all other operations, it must be returned as null
or not included in the output.
Prerequisites
Steps to reproduce
run
dsc config test
passing in configExpected behavior
Actual behavior
Error details
No response
Environment data
Version
alpha4
Visuals
No response