Automation Rules

In this page

Automation rules

Automation rules are the actual mechanisms that implement your automated DevOps pipelines. The following sections explain the general topics on rules and offer links to learn more about its components.

Anatomy of an automation rule

Automation rules allow you to automate actions within your system based on criteria that you set. Learn more about automation rules.

Rules are made up of three components:

1. triggers that kick off the rule
2. conditions that refine the rule
3. actions that perform tasks in your site

Every rule starts with a trigger. They kick off the execution of your rules. Triggers will listen for events in Jira, such as when an issue is created or when a field value is changed. Learn more about the built-in triggers and about the DevOps triggers.

Conditions allow you to narrow the scope of your rule. They must be met for your rule to continue running. Learn more about conditions and about conditional DevOps rules.

Actions are the doers of your rule. They allow you to automate tasks and make changes within your Jira and other systems. Learn more about the built-in actions and about the DevOps automation actions.

Executing automation rules

This section explains important aspects of rule execution.

Rule actors

The rule actor is a configuration setting for an automation rule. The actor is the Jira user who executes the actions in the rule, consequently the actor will also be the author of the resulted changes.

As a best practice, it's recommended to create a dedicated Jira user intuitively called "devopsbot" and configure all DevOps automation rules with this user as actor. Doing so, later it will be easier to manage the permissions for the DevOps automation rules, and it will be easier to see which changes were resulted from DevOps automations.

Does it actually matter who is the actor?

• In some cases like sending an HTTP request to an external URL, it does not matter who is the actor.
• In other cases, like commenting an issue, it does matter because although you'd expect the committer as the comment author, the actor will be that! This is because the Automation for Jira app executes automation actions on behalf of the actor. Note that although this is how Automation for Jira works at the moment, there are workarounds to overcome this limitation, just read on.

Depending on how important the identity of the committer is, you have the following options, demonstrated with the "comment issue" use case:

1. Not important: use the built-in Comment on issue action with this comment text template:

   {{devops.comment}}
   

   It will create the comment on behalf of the actor. (The committer will not be captured anywhere.)
2. Nice to know: use the built-in Comment on issue action with this comment text template:

   {{devops.comment}}
   
   (Created by {{devops.committerByUsername.name}} via Git.)
   

   It will create the comment on behalf of the actor, but the committer will be captured in the comment text.
3. Important: use the Run Groovy script action because it allows creating the comment on behalf of the committer! (This is an automation action provided by the Better DevOps Automation app which can run Groovy scripts.)
   There is a short Groovy scripts in our configuration guide that takes the committer and creates the comment on behalf of this user account. You can just copy and paste the Groovy script to your action, and result will be perfect!

The three approaches would create these three comments:

Again, the workaround is needed only because of the known limitation in Automation for Jira Data Center. (Surprisingly, the same limitation does not exist in the Automation for Jira Cloud!) To ask for the removal of this limitation, please leave a comment in this Atlassian Community topic and also like the topic itself.

Error handling

Rule execution may fail due to insufficient permissions, changed workflows, incorrectly formed Genius Commits, mis-configured actions and others. Because rules are executed asynchronously in the background, the committer will not see the error message immediately.

Instead, the result of the executions can be checked in the audit log of the rule:

Please note that it is possible to receive email notifications about the errors so that the owner of the rule doesn't need to regularly check for those. Notifications can be configured in the rule details.

Questions?

Ask us any time.