Rules with this trigger can only be invoked manually. The simple use case that it addresses is when we want to generate release notes on an ad-hoc basis.

Open

Steps to trigger rule manually

When the trigger is set to Manual, you can trigger/execute it using button available on the rules listing page or rule’s detail page. Refer to the below screenshot.

Open

Clicking on opens the pop-up that expects input/s from the end user. Once the input/s is/are provided & user clicks on Ok all the actions within the manual rule will be executed. This is what the input selector pop-up looks like. If no inputs are needed, a message to that effect will be displayed in the pop-up.

Open

This trigger is used to automate your release notes & reports when a new version is created in Jira. To make this possible, your template should have variables like [versionId] and/or [versionName]. As soon as a new version is created in the given Jira project, rules that have this trigger will get executed, and based on the actions in the rule, the relevant template will be executed to fetch the content from Jira.

Open

You can also user the regular expression for conditional rule execution. The rule will be executed only for those versions whose name matches the regular expression filter, others will be skipped. If unchecked, rule will be executed for all versions that are created in Jira.

What type of regular expressions are allowed - https://www.freeformatter.com/java-regex-tester.html

Version id/name is the input parameter for this trigger. But this parameter is passed from the Jira version release action to the ARNR rule. Thus as soon as a version is released in Jira, rules that have this trigger will be executed. 

Open

You can also user the regular expression for conditional rule execution. The rule will be executed only for those versions whose name matches the regular expression filter, others will be skipped. If unchecked, rule will be executed for all versions that are created in Jira.

What type of regular expressions are allowed - https://www.freeformatter.com/java-regex-tester.html

If certain rules are needed to be executed before the planned release date on a recurring frequency, schedule them using this trigger. For a scheduled trigger, the system expects the number of days parameter from you. The 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. The 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.

Open

You can also user the regular expression for conditional rule execution. The rule will be executed only for those versions whose name matches the regular expression filter, others will be skipped. If unchecked, rule will be executed for all versions that are created in Jira.

What type of regular expressions are allowed - https://www.freeformatter.com/java-regex-tester.html

It is possible to execute rules at regular intervals 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 input variable/s (i.e. versionId, versionName, versionDesc, etc) are not used at all.

Open

You can use this helper tool to customize the cron expression to meet your needs

To automate the execution of rules based on when Sprint started use Sprint started trigger and publish relevant release notes, documents, and reports for the sprints created in Jira project(s). When this trigger is selected, the rule is triggered whenever a sprint is marked as started in the project and relevant release notes will be published to end users based on given template and rule configuration.

Open

If the templates in your rule actions are based on Sprint input variables, it makes sense to automatically trigger that rule when a Sprint is completed. That’s what this trigger does.

Open

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.

Open

In this case, webhook endpoint refers/considers the variables provided in the selected template in a rule action. You can use the GET or POST request type as needed.

Notice that the GET & POST action provides the list of version and sprint variables in the template.

Open

Open

Triggering webhook rule via the link with version names

Once you save the rule with the Webhook trigger and get the Webhook link, you can paste the link in browser to run the rule by passing ARNR variables in the same link. Example -

Link received after saving the rule with a webhook trigger - https://arn.upraise.io/arn/executewebhook/bdb42669-8181-4d77-afe6-f7c7193ec0?version={versionName}

In above link you can replace the {versionId} variable with the actual variable value in double quotes for eg. in this case version id is “apple v1.2.0” so the webhook link you would hit in browser is -

https://arn.upraise.io/arn/executewebhook/bdb42669-8181-4d77-afe6-f7c7193ec041?version=“apple v1.2.0”

Triggering webhook for the 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 the corresponding version variables. No authentication is needed. You can even do that directly via the 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.