Jira automation with ScriptRunner

When I process my tickets in Jira and move them through the statuses, I often don’t even notice what’s happening in the background – as if by magic, assignees are assigned, fields are updated and notifications are sent. Of course, this has nothing to do with magic, but with Jira’s built-in automation. Thanks to automation rules, actions can be executed based on specific events or conditions. Workflows also offer the option of using triggers, conditions, validators and follow-up functions during status transitions to make processes even more precise. A whole range of predefined, often configurable functions are available for this purpose.

But what if these standard automations are not sufficient and the processes are more complex? This is exactly where Jira ScriptRunner comes into play. This is a paid add-on for Jira that is used in many companies. With custom Groovy scripts, you can tailor automations, adapt data specifically and even create tickets automatically – in short, ScriptRunner gives you full control over your Jira processes.

I will show you exactly how this works in practice using specific examples from my last project at a company in the insurance industry. You will see that scripts can be used to automatically create subtasks, fill in custom fields and even enable cross-tool automation. Sound exciting? Then let’s get started!

The project: Automating the Jira process for setting up and restructuring test environments

The goal of our project was to develop a new, script-supported process for providing test environments. Simply put, these are computers on which specific software runs in a predefined state so that they can be used for testing. The new process was intended to increase the efficiency of provisioning, minimise manual effort and reduce sources of error.

The most important goals of the project that are relevant to this article can be summarised as follows:

• Reduction of manual effort: Automatic creation of subtasks and automatic updating of Confluence pages.
• Introduction of quality gates: Automatic tests to ensure that the provisioned environment is correct.

To achieve these goals, we created a new Jira project called ‘Environment Management.’ This project includes the process types ‘Environment Request’ and ‘Environment.’ An environment request is created when a new environment is needed; it contains the desired target configuration. The environment ticket then represents the actual test environment with the current configuration. Individual workflows have been developed for both task types.

The process is as follows: First, a requester creates an environment request and fills it with important data such as the deadline and the software to be installed, including the software versions to be used. An employee from the environment management team then adds any missing data and completes the planning. This is where automation comes into play: An automatic completeness check is performed, the environment ticket is created with the data from the environment request, and a new Confluence page is created (if it does not already exist) and updated with the information from the environment ticket. The necessary subtasks for setting up or rebuilding the environment are then created automatically.

In addition, various quality gates have been integrated into the project as Jenkins pipelines. These check, for example, whether the correct software is installed in the correct versions or whether test data has been anonymised correctly. Links in the subtasks allow these quality gates to be called up in Jenkins and the results to be displayed directly in the environment ticket in Jira using a traffic light system that indicates the status.

I would now like to show you how we implemented all this with ScriptRunner using specific examples. Features such as workflows, listeners, REST endpoints and fields are used.

Workflow: Validator as mandatory field check

Workflow validators ensure that certain conditions are met before a status transition is carried out. If the conditions are not met, the transition is not carried out and an error message is displayed to inform the user what needs to be corrected.

In our project, we developed a validator that checks mandatory fields in the environment request when transitioning to the ‘In progress’ status – and not just blindly, but with a certain degree of intelligence. This is because it was not always sufficient to simply require that all fields be filled in. Sometimes the mandatory nature of a field depended on what was entered in another field. This is exactly what our validator does: it not only checks whether something has been entered, but also whether the combinations make sense.

For example, there are some fields that must always be filled in, such as whether it is a new installation or a conversion, what type of environment is required, or whether the software should be installed as a full or single deployment. But not every combination is allowed. A complete rebuild of the environment? Then the ‘single deployment’ option should not be available at all; it must be a full deployment. If this information is missing or incorrect, the validator blocks the status transition and displays a clear error message:

Workflow: Follow-up function for automatic creation of subtasks

Workflow follow-up functions ensure that certain actions are performed automatically after a status transition. For example, you can update fields, add comments or send notifications.

In our project, there was a requirement that subtasks be created automatically when an environment request reached the ‘In progress’ status. While Jira board tools can create simple subtasks, the logic here was so complex that we had to develop our own follow-up function. The task was to determine which subtasks were to be created, what text they should contain, and what dependencies existed between them.

To do this, template subtasks were defined. Templates contain predefined text with placeholders that are automatically replaced with information from the environment request when the actual subtasks are created. We also defined conditions that determine what information must be present in the environment request for a subtask to be created. Images, attachments and dependencies to other templates could even be stored in the templates and transferred when the subtasks were created. In addition, email templates were integrated that send an email with predefined text when a subtask reaches a certain status.

The script then evaluates all relevant information from the environment request and the templates, creates the appropriate subtasks, replaces the placeholders and links the subtasks to each other according to the defined template links. Sounds complicated? It was! But in the end, it worked wonderfully.

Listener: Updating the Confluence page of an environment

Listeners in Jira ScriptRunner respond to specific events, such as the creation, update or modification of tickets. They enable actions to be performed automatically as soon as a defined event occurs.

A concrete example from our project is the automatic updating of the associated Confluence page as soon as an environment ticket is saved. This was implemented by accessing Confluence via REST API. The script searches for the appropriate page based on the environment name stored in the environment ticket. If the page does not yet exist, it is recreated based on a template. The script then fills a table on the page with the relevant data from the environment ticket. This task used to be done manually, so this is a real relief for employees.

REST Endpoints: Store quality gate results from Jenkins in Jira

REST Endpoints in Jira ScriptRunner allow you to create custom API endpoints that respond to HTTP requests. This makes it easy to communicate between Jira and external systems.

Thanks to this endpoint, we were able to receive the results of our quality gates from Jenkins directly in Jira. Every time a quality gate pipeline runs in Jenkins, the result is sent as JSON to our endpoint. This stores the data in a file on the Jira server, which consolidates all quality gate results for all environments. What happens to this data is described in the next section and can also be seen in the following illustration.

Fields: Displaying quality gate results in the environment ticket

ScriptRunner Fields allow you to create custom fields that contain dynamic values. These values can come from Jira data or external sources and can even be displayed in HTML format.

We used this feature to display the results of the quality gates in Jira with a traffic light icon. To do this, we created two fields: one for the overall status of all quality gates in an environment for display in a dashboard and one for the detailed results. The data source for this is the file created via the REST endpoint. The content of the detail field, as displayed in the environment ticket, looks something like this:

Conclusion

ScriptRunner has proven to be an indispensable tool for our environment management project. All automations were implemented with ScriptRunner, from simple fields to complex workflow sequence functions.

Developing the scripts is also fun – it offers scope for creative solutions and, with a little practice, can be made very efficient. Even those with no programming experience can create and customise smaller scripts using AI. This makes ScriptRunner a valuable tool not only for developers, but also for technically savvy administrators.

Notes

Would you like to expand JIRA for your projects? Then talk to us about your project.

Here you can find more information about Jira ScriptRunner.

If you like the article or would like to discuss it, please feel free to share it in your network. And if you have any comments, please do not hesitate to send us a message.