Triggers
What are triggers?
Triggers are what start execution of any rule (& subsequently actions). ARN supports following types of triggers at the moment.
Manual
Rules with this trigger can only be invoked manually. Simple use case that it addresses is, when we want to generate release notes on an ad-hoc basis.
Version created
Version id/name is the input parameter for this trigger. But this parameter is passed from Jira version create action to the ARN rule. Thus as soon as a new version is created in the given Jira project, rules that have this trigger will get executed.
Version release
Version id/name is the input parameter for this trigger. But this parameter is passed from Jira version release action to the ARN rule. Thus as soon as a version is released in Jira, rules that have this trigger will be executed.
Scheduled before N days of release
If certain rules are needed to be executed before planned release date on a recurring frequency, schedule them using this trigger. For a scheduled trigger, system expects number of days parameter from you. Idea is to send pre-release emails e.g. send pre-release notes 4 days before the planned release date or 10 days before the release date etc. Planned release date is picked up from Versions defined in your Jira project.
Additionally, you can also configure the timezone & time on which this trigger should run on the given day.
Conditional trigger
Version create, Version release, Scheduled before N days of release triggers allow for additional customisation - Enable conditional trigger
This lets end users define regular expressions to match against the version name. If the version name matches configured regular expression, rule will be executed else it will be skipped.
What type of regular expressions are allowed - https://www.freeformatter.com/java-regex-tester.html
Scheduled at interval
It is possible to execute rules at a regular interval with the help of this trigger. Simply provide a cron expression & timezone as input. Do keep in mind that no version is passed to the actions within this rule, when the rule is executed. Thus, for such a rule - ideally all of the actions should have templates where version variable/s (i.e. versionId, versionName, versionDesc etc) are not used at all.
You can use following helper tool to customise the cron expression to meet your needs - http://www.cronmaker.com/
Webhook
If certain rules are needed to be executed only after some processes in other applications are completed, use the webhook trigger. e.g. if you want a certain version's release notes to be triggered only after the build is deployed successfully on the test environment.
Note
The webhook endpoint expects Version ID & not Version name.
Multiple versions can be provided to the webhook (e.g. by using ?version=10000&version=10001)
Triggering webhook for Cloud version
For the cloud version of the app, it is very easy to trigger the webhook. You just have to copy the webhook URL and hit it with corresponding version variables. No authentication is needed. You can even do that directly via browser just to verify it.
Triggering webhook for Server/DC version
For server/DC version of the app, you have to send a GET request to the webhook URL. Additionally with the GET request, provide an Authorization header with content Basicfollowed by the encoded string generated from https://www.base64encode.org/ for username:password
That is, authentication is needed to trigger the webhook in this case.