The trigger in a rule specifies which incoming events should be inspected for potential match against this rule.
View all the triggers configured on a system via the command line with the st2triggerlist command:

Rule criteria are the rule(s) needed to be matched against (logical AND). Criteria in the rule is expressed as:

# more variablescriteria:trigger.payload_parameter_name1:type:"regex"pattern:"^value$"trigger.payload_parameter_name2:type:"iequals"pattern:"watchevent"

Note

You can achieve logical OR behavior (either one of multiple criteria expressions needs to
match for the action execution to be triggered) by creating multiple independent rules (one per
criteria expression).

type specifies which criteria comparison operator to use and pattern specifies a pattern
which gets passed to the operator function.

In the regex case, pattern is a regular expression pattern which the trigger value
needs to match.

A list of all the available criteria operators is described below. If you are missing some
operator, you are welcome to code it up and submit a patch :)

If the criteria key contains an special characters (like -) then use the dictionary lookup format for specifying
the criteria key. In case of a webhook based rule it is typical for the header of the posted event to
contain such values e.g.:

Trigger value matches the provided wildcard-like string. This
operator provides support for Unix shell-style wildcards which
means you can use characters such as * and ?. This
operator is preferred over regex for simple string
matches.

This section describes the subsequent action/workflow to be executed on a successful match of a trigger
and an optional set of criteria. At a minimum, a rule should specify the action to execute. Additionally,
a rule can also specify parameters that will be supplied to an action upon execution.

Value of trigger attribute can be null and None. It is also a valid value of the action
parameter in question. You need to use the use_none Jinja template filter to make sure that
null / None values are correctly serialized when invoking an action.

This workaround is required because of the limitation of our current templating system Jinja
which doesn’t support non-string types. We are forced to perform type casting based on the
action parameters definition before invoking an action.

To deploy a rule, use CLI st2rulecreate${PATH_TO_RULE} command, To reload all the rules,
use st2ctlreload--register-rules for example:
=======
To deploy a rule, use the CLI command: st2rulecreate${PATH_TO_RULE}, for example:

Hint: It is a good practice to always edit the original rule file, so that keep your infrastructure in code. You still can get the rule definition from the system by st2ruleget<rulename>-j, update it, and load it back.

To see all the rules, or to get an individual rule, use commands below:

st2 rule list
st2 rule get examples.sample_rule_with_webhook

To undeploy a rule, run st2ruledelete${RULE_NAME_OR_ID}. For example, to undeploy the examples.sample_rule_with_webhook rule we deployed previously, run:

Custom rules can be placed in any accessible folder on local system. By convention, custom rules are placed
in the /opt/stackstorm/packs/default/rules directory. By default, BWC doesn’t load the rules
deployed under /opt/stackstorm/packs/${pack_name}/rules/. However you can force load them with
st2runpacks.loadregister=rules or st2runpacks.loadregister=all.

payload - Trigger payload. The payload itself is specific to the trigger in question. To
figure out the trigger structure you can look at the pack README or look for the
trigger_types section in the sensor metadata file which is located in the packs/<packname>/sensors/ directory.

If the trigger instance matches, ===RULEMATCHES=== will be printed and the tool will exit
with 0 status code. On the other hand, if the rule doesn’t match,
===RULEDOESNOTMATCH=== will be printed and the tool will exit with 1 status code.

st2-rule-tester further allows a kind of post-mortem debugging where you can answer the
question Whydidmyrulenotmatchthetriggerthatjustfired?. This means there is known
Rule identifiable by its reference loaded in BWC and similarly a TriggerInstance
with a known id.

Lets say we have rule reference my_pack.fire_on_execution and a trigger instance 566b4be632ed352a09cd347d

Timers allow running a particular action repeatedly based on a defined time interval or one
time at a particular date and time. You can think of them as cron jobs, but with additional
flexibility, e.g. ability to run actions only once, at the provided date and time.

Currently, we support the following timer trigger types:

core.st2.IntervalTimer - Run an action at predefined time intervals (e.g. every
30 seconds, every 24 hours, every week, etc.).

core.st2.DateTimer - Run an action at the specified date and time.

core.st2.CronTimer - Run an action when current time matches the time constraint
defined in UNIX cron format.

Timers are implemented as triggers, which means you can use them inside the rules. In the section
below, you can find some examples on how to use timers in the rule definitions.

By default, if no value is provided for a particular parameter, * is assumed, which means
fire on every value.

Note

Unlike with cron where first day (0) in day_of_week is a Sunday, in BWC CronTimer
first day of the week is always Monday. To make it more explicit and avoid confusion, you are
encouraged to use name of the weekdays instead (e.g. mon-fri instead of 0-4, or in
cron case, 1-5).