Page History
...
Jira Automation allows project administrators to implement automation rules that can be used to make certain processes are automated, guaranteeing efficiency and also ensure processes are assuredconsistency.
The main concepts of Jira Automation follows follow a very simple approach for defining an automation rule: if a certain "thing" happens (trigger) and certain conditions are met, then execute one or more actions.
- Trigger: Triggers start the execution of a rule. Triggers can listen for events or be scheduled to run.
- manual
- upon changes on fields, on the field or workflow status changes
- upon releasing
- periodic
- ...
- Condition: Actions will only execute if all conditions preceding them pass.
- "If" statement
- Issue fields condition
- ...
- Action: Actions perform changes to a system.
- change fields on issues
- transition issues
- web request
- log
- ...
...
It's also possible to run actions on issues that are related to the issue that triggered the rule, using "branches".
...
| Info | ||
|---|---|---|
| ||
Automation rules run asynchronously. Some actions can run in parallel but usually they're sequential. There is no interaction with the user (except if the trigger was triggered set off manually from Jira's UI). |
...
- create a new rule and define the "When" (i.e. when it to should be triggered) , to be "Issue linked". Since Xray, by default, uses the issue link type "Tests" to establish the coverage relation between a Test and the requirement, we can take advantage of that to trigger the rule whenever such issue link is created.
- create a condition to ensure that the rule only runs for Test issues
- use a an "Edit issue" action to set the fields on the Test , based on the field fields of the linked requirement/Story (i.e., the destination issue of the issue linking event). In this example, we'll copy the values of Urgency and Probability custom fields.
...
- whenever a Test is created from the requirement/Story issue screen
- whenever a Test has been initially created and linked later on linked to the requirement
Reopen/
...
transitionTests linked
...
to a requirement
...
whenever
...
the requirement is transitioned or
...
changed
Whenever you change the specification of a requirement/story, you most probably will need to review the Tests that you have already specified.
The following rule tries to make perform a transition on of all Tests linked Tests to a requirement.
Automation configuration
On the Jira side we will use the Automation capabilities that it provides out of the box, so within the administration area go to the automation entry in the system settings and:
- create a new rule and define the "When" (i.e. when it to should be triggered) , to be "Field value changechanged"
- Note: we could also define the trigger to be based on the transition of the requirement issue to a certain workflow status; in that case we would define it, for example, as shown aheadbelow.
- create a condition to ensure that the rule only runs for Story and Epic issues; adjust these to include all the "requirement" issue types (i.e., the ones that you can cover with Tests)
- create a "branch rule / related issues" to obtain related Tests using JQL and the
requirementTests()JQL function and run one, or more, action(s) on them - under the "For JQL" block, create a action "Transition the issue to" in order to reopen the related Test issues
...