en-US/about_PSRule_Keywords.help.txt

TOPIC
    about_psrule_keywords
 
SHORT DESCRIPTION
    Describes the language keywords that can be used within PSRule rule
    definitions.
 
LONG DESCRIPTION
    PSRule lets you define rules using PowerShell blocks. To define a rule use
    the `Rule` keyword.
    -
    Rule
    - Creates a rule definition.
    The following are the built-in keywords that can be used within a rule definition:
    -
    AnyOf
    - Assert that any of the child expressions must be true. -
    AllOf
    - Assert that all of the child expressions must be true. -
    Exists
    - Assert that a field or property must exist. -
    Match
    - Assert that the field must match any of the regular expressions. -
    Reason
    - Return a reason for why the rule failed. -
    Recommend
    - Return a recommendation to resolve the issue and pass the rule. -
    TypeOf
    - Assert that the object must be of a specific type. -
    Within
    - Assert that the field must match any of the values.
    A subset of built-in keywords can be used within script preconditions:
    -
    Exists
    - Assert that a field or property must exist. -
    Match
    - Assert that the field must match any of the regular expressions. -
    TypeOf
    - Assert that the object must be of a specific type. -
    Within
    - Assert that the field must match any of the values.
 
    RULE
    A `Rule` definition describes an individual business rule that will be
    executed against each input object. Input objects can be passed on the
    PowerShell pipeline or supplied from file.
    To define a Rule use the `Rule` keyword followed by a name and a pair of
    squiggly brackets `{`. Within the `{ }` one or more conditions can be used.
    Conditions determine if the input object either
    Pass
    or
    Fail
    the rule.
Syntax:
 
    Rule [-Name] <string> [-Ref <string>] [-Alias <string[]>] [-Tag <hashtable>] [-When <string[]>] [-Type <string[]>] [-If <scriptBlock>] [-DependsOn <string[]>] [-Configure <hashtable>] [-ErrorAction <ActionPreference>] [-Body] {
        ...
    }
 
    - `Name` - The name of the rule definition. Each rule name must be unique.
    When packaging rules within a module, rule names must only be unique within
    the module. - `Ref` - An optional stable and opaque identifier that can be
    used to reference the rule.
    - `Alias` - A list of alternative names that can be used to reference the rule.
    - `Tag` - A hashtable of key/ value metadata that can be used to filter and
    identify rules and rule results.
    - `When` - A selector precondition that must evaluate true before the rule
    is executed.
    - `Type` - A type precondition that must match the
    TargetType
    of the pipeline object before the rule is executed. - `If` - A script
    precondition that must evaluate to `$True` before the rule is executed.
    - `DependsOn` - A list of rules this rule depends on.
    Rule dependencies must execute successfully before this rule is executed. -
    `Configure` - A set of default configuration values. These values are only
    used when the baseline configuration does not contain the key. -
    `ErrorAction` - The action to take when an error occur. Only a subset of
    preferences are supported, either `Stop` or `Ignore`. When `-ErrorAction` is
    not specified the default preference is `Stop`. When errors are ignored a
    rule will pass or fail based on the rule condition. Uncaught exceptions will
    still cause rule return an error outcome. - `Body` - A script block that
    specifies one or more conditions that are required for the rule to
    Pass
    .
    A condition is any valid PowerShell that return either `$True` or `$False`.
    Optionally, PSRule keywords can be used to help build out conditions
    quickly. When a rule contains more then one condition, all must return
    `$True` for the rule to
    Pass
    . If any one condition returns `$False` the rule has failed.
    The following restrictions apply:
    - Rule conditions should only return `$True` or `$False`. Other objects
    should be caught with `Out-Null` or null assigned like `$Null = SomeCommand`.
    - The `Rule` keyword can not be nested in a `Rule` definition.
    - Variables and functions defined within `.Rule.ps1` files, but outside the
    `Rule` definition block are not accessible unless the `Global` scope is applied.
    - Functions and variables within the caller's scope (the scope calling
    `Invoke-PSRule`, `Get-PSRule`, `Test-PSRuleTarget`) are not accessible.
    - Cmdlets that require user interaction are not supported, i.e. `Read-Host`.
    - Script preconditions can contain `Exists`, `Match`, `TypeOf` and `Within` keywords.
    Examples:
 
    # Synopsis: This rule checks for the presence of a name field
    Rule 'NameMustExist' {
        Exists 'Name'
    }
 
    # Synopsis: This rule checks that the title field is valid, when the rule NameMustExist is successful
    Rule 'TitleIsValid' -DependsOn 'NameMustExist' {
        Within 'Title' 'Mr', 'Miss', 'Mrs', 'Ms'
    }
 
    # Synopsis: This rule uses a threshold stored as $Configuration.minInstanceCount
    Rule 'HasMinInstances' {
        $TargetObject.Sku.capacity -ge $Configuration.minInstanceCount
    } -Configure @{ minInstanceCount = 2 }
 
    # Synopsis: This rule still passes because errors are ignored
    Rule 'WithRuleErrorActionIgnore' -ErrorAction Ignore {
        Write-Error 'Some error';
        $True;
    }
 
    EXISTS
    The `Exists` assertion is used within a `Rule` definition to assert that a
    field
    or property must exist on the pipeline object.
Syntax:
 
    Exists [-Field] <string[]> [-CaseSensitive] [-Not] [-All] [-Reason <string>] [-InputObject <PSObject>]
 
    - `Field` - One or more fields/ properties that must exist on the pipeline object.
    - `CaseSensitive` - The field name must match exact case.
    - `Not` - Instead of checking if the field names exists they should not exist.
    - `All` - All fields must exist on the pipeline object, instead of only one.
    - `Reason` - A custom reason provided if the condition fails.
    - `InputObject` - Supports objects being piped directly.
    Examples:
 
    # Synopsis: Checks for the presence of a name property
    Rule 'nameMustExist' {
        Exists 'Name'
    }
 
    # Synopsis: Checks for the presence of name nested under the metadata property
    Rule 'nameMustExist' {
        Exists 'metadata.name'
    }
 
    # Synopsis: Checks for the presence of name nested under the metadata property
    Rule 'nameMustExist' {
        $TargetObject.metadata | Exists 'name'
    }
 
    # Synopsis: Checks that the NotName property does not exist
    Rule 'NotNameMustNotExist' {
        Exists -Not 'NotName'
    }
 
    # Synopsis: Checks one of Name or AlternativeName properties exist
    Rule 'EitherMustExist' {
        Exists 'Name', 'AlternativeName'
    }
 
    # Synopsis: Checks that both Name and Type properties exist
    Rule 'AllMustExist' {
        Exists 'Name', 'Type' -All
    }
 
    Output:
If
    any
    the specified fields exists then `Exists` will return `$True`, otherwise `$False`.
    If `-Not` is used, then if
    any
    of the fields exist then `Exists` will return `$False` otherwise `$True`.
    If `-All` is used, then then
    all
    of the fields must exist, or not with the `-Not` switch. If all fields exist
    then `Exists` will return `$True`, otherwise `$False`. If `-Not` is used
    with `-All`, if
    all
    of the fields exist `Exists` will return `$False` otherwise `$True`.
 
    MATCH
    The `Match` assertion is used within a `Rule` definition to assert that the
    value of a
    field
    or property from pipeline data must match one or more regular expressions.
    To optionally perform a case sensitive match use the `-CaseSensitive`
    switch, otherwise a case insensitive match will be used.
    Syntax:
 
    Match [-Field] <string> [-Expression] <string[]> [-CaseSensitive] [-Not] [-Reason <string>] [-InputObject <PSObject>]
 
    - `Field` - The name of the field that will be evaluated on the pipeline object.
    - `Expression` - One or more regular expressions that will be used to match
    the value of the field.
    - `CaseSensitive` - The field
    value
    must match exact case. - `Not` - Instead of checking the field value
    matches, the field value must not match any of the expressions.
    - `Reason` - A custom reason provided if the condition fails.
    - `InputObject` - Supports objects being piped directly.
    Examples:
 
    # Synopsis: Check that PhoneNumber is complete and formatted correctly
    Rule 'validatePhoneNumber' {
        Match 'PhoneNumber' '^(\+61|0)([0-9] {0,1}){8}[0-9]$'
    }
 
    Output:
If
    any
    of the specified regular expressions match the field value then `Match`
    returns `$True`, otherwise `$False`.
    When `-Not` is used, if any of the regular expressions match the field value
    with `Match` return `$False`, otherwise `$True`.
 
    WITHIN
    The `Within` assertion is used within a `Rule` definition to assert that the
    value of a field or property from pipeline data must equal an item from a
    supplied list of allowed values. To optionally perform a case sensitive
    match use the `-CaseSensitive` switch, otherwise a case insensitive match
    will be used.
    Syntax:
 
    Within [-Field] <string> [-Not] [-Like] [-Value] <PSObject[]> [-CaseSensitive] [-Reason <string>] [-InputObject <PSObject>]
 
    - `Field` - The name of the field that will be evaluated on the pipeline object.
    - `Value` - A list of values that the field value must match.
    - `CaseSensitive` - The field
    value
    must match exact case. Only applies when the field value and allowed values
    are strings. - `Not` - Instead of checking the field value matches, the
    field value must not match any of the supplied values.
    - `Like` - Instead of using an exact match, a wildcard match is used.
    This switch can only be used when `Value` a string type. - `Reason` - A
    custom reason provided if the condition fails.
    - `InputObject` - Supports objects being piped directly.
    Examples:
 
    # Synopsis: Ensure that the title field has one of the allowed values
    Rule 'validateTitle' {
        Within 'Title' 'Mr', 'Miss', 'Mrs', 'Ms'
    }
 
    # Synopsis: Ensure that the title field is not one of the specified values
    Rule 'validateTitle' {
        Within 'Title' -Not 'Mr', 'Sir'
    }
 
    # Synopsis: Ensure that the title field has one of the allowed values
    Rule 'validateTitle' {
        Within 'Title' -Like 'Mr', 'M*s'
    }
 
    Output:
If
    any
    of the values match the field value then `Within` returns `$True`, otherwise `$False`.
    When `-Not` is used, if any of the values match the field value with
    `Within` return `$False`, otherwise `$True`.
    When `-Like` is used, the field value is matched against one or more
    wildcard expressions.
 
    ALLOF
    The `AllOf` assertion is used within a `Rule` definition to aggregate the
    result of assertions within a pair of squiggly brackets `{ }`. `AllOf` is
    functionally equivalent to a binary
    and
    , where when all of the contained assertions return `$True`, `AllOf` will
    return `$True`.
    Syntax:
 
    AllOf [-Body] {
        <assertion>
        [<assertion>]
        ...
    }
 
    - `Body` - A script block definition of the containing one or more PSRule
    keywords and PowerShell expressions.
    Examples:
 
    # Synopsis: The Name field must exist and have a value of either John or Jane
    Rule 'nameCheck' {
        AllOf {
            Exists 'Name'
            Within 'Name' 'John', 'Jane'
        }
    }
 
    Output:
If
    all
    of the assertions return `$True` AllOf will return `$True`, otherwise
    `$False`.
 
    ANYOF
    The `AnyOf` assertion is used within a `Rule` definition to aggregate the
    result of assertions within a pair of squiggly brackets `{ }`. `AnyOf` is
    functionally equivalent to a binary
    or
    , where if any of the contained assertions returns `$True`, `AnyOf` will
    return `$True`.
    Syntax:
 
    AnyOf [-Body] {
        <assertion>
        [<assertion>]
        ...
    }
 
    - `Body` - A script block definition of the containing one or more PSRule
    keywords and PowerShell expressions.
    Examples:
 
    # Synopsis: The Last or Surname field must exist
    Rule 'personCheck' {
        AnyOf {
            Exists 'Last'
            Exists 'Surname'
        }
    }
 
    Output:
If
    any
    of the assertions return `$True` AnyOf will return `$True`, otherwise
    `$False`.
 
    TYPEOF
    The `TypeOf` assertion is used within a `Rule` definition to evaluate if the
    pipeline object matches one or more of the supplied type names.
    Syntax:
 
    TypeOf [-TypeName] <string[]> [-Reason <string>] [-InputObject <PSObject>]
 
    - `TypeName` - One or more type names which will be evaluated against the
    pipeline object. `TypeName` is case sensitive. - `Reason` - A custom reason
    provided if the condition fails.
    - `InputObject` - Supports objects being piped directly.
    Examples:
 
    # Synopsis: The object must be a hashtable
    Rule 'objectType' {
        TypeOf 'System.Collections.Hashtable'
    }
 
    Output:
If
    any
    the specified type names match the pipeline object then TypeOf will return
    `$True`, otherwise `$False`.
 
    REASON
    The `Reason` keyword is used within a `Rule` definition to provide a message
    that indicates the reason the rule failed. The reason is included in
    detailed results.
    A reason is only included when the rule fails or errors. The outcomes `Pass`
    and `None` do not include reason.
    Use this keyword when you want to implement custom logic. Built-in keywords
    including `Exists`, `Match`, `Within` and `TypeOf` automatically include a
    reason when they fail.
    Syntax:
 
    Reason [-Text] <string>
 
    - `Text` - A message that includes the reason for the failure.
Examples:
 
    # Synopsis: Provide reason the rule failed
    Rule 'objectRecommend' {
        Reason 'A minimum of two (2) instances are required'
        $TargetObject.count -ge 2
    }
 
    Output:
None.
 
    RECOMMEND
    The `Recommend` keyword is used within a `Rule` definition to provide a
    recommendation to resolve the issue and pass the rule. This may include
    manual steps to change that state of the object or the desired state
    accessed by the rule.
    The recommendation can only be set once per rule. Each object will use the
    same recommendation.
    Syntax:
 
    Recommend [-Text] <string>
 
    - `Text` - A message that includes the process to resolve the issue and pass
    the rule.
    Examples:
 
    # Synopsis: Provide recommendation to resolve the issue
    Rule 'objectRecommend' {
        Recommend 'Use at least two (2) instances'
        $TargetObject.count -ge 2
    }
 
    Output:
None.
 
EXAMPLES
    # Synopsis: App Service Plan has multiple instances
    Rule 'appServicePlan.MinInstanceCount' -If { $TargetObject.ResourceType -eq 'Microsoft.Web/serverfarms' } {
        Recommend 'Use at least two (2) instances'
     
        $TargetObject.Sku.capacity -ge 2
    }
 
NOTE
    An online version of this document is available at
    https://microsoft.github.io/PSRule/v2/keywords/PSRule/en-US/about_PSRule_Keywords/.
 
SEE ALSO
    - [Invoke-PSRule]
 
KEYWORDS
    - Rule
    - Exists
    - Match
    - AnyOf
    - AllOf
    - Within
    - TypeOf
    - Reason
    - Recommend
    [Invoke-PSRule]:
    https://microsoft.github.io/PSRule/v2/commands/PSRule/en-US/Invoke-PSRule/