Actions

Cloud

Actions are the building blocks of rules that will actually do something. They can create an issue, transition an issue, comment on an issue.

Comment on Issue
Create Issue
Create Version
Edit Issue
Transition Issue

Comment on Issue

Issue Selector

Select the selection method used to select the issues to add the comment on.

Linked to Build

Select this method to select all the issues that are linked to the build that was synchronized. Refer to the Data Synchronization documentation on how builds are linked to issues.

This method is only available in combination with the Build Synchronized event.

Linked to Job

Select this method to select all the issues that are linked to the job that was synchronized (when using the Job Synchronized event) or the job of the build that was synchronized (when using the Build Synchronized event). Refer to the Data Synchronization documentation on how builds are linked to issues.

This method is only available in combination with either the Job Synchronized or the Build Synchronized events.

From Expression

Select this method if you want to limit issue selection to specific attributes of the trigger event or even a static value.

When selecting this method you must also specify the expression used to search for issues to transition. For instance, if you only want to select issues that are mentioned in the job description, then you can use this expression [[job.description]] or [[build.job.description]]. You can also combine attributes, e.g. [[job.displayName]] [[job.description]], or even attributes with static text, DEV-1, DEV-2, [[build.description]]. See Expression Values for details on the attributes that are available.

JQL

Select this method if you want to limit the issue selection to issues matching a specifc JQL search result. The JQL can also include attributes of the trigger event. See Expression Values for details on the attributes that are available.

None

Select this method if you don’t want to select any issues for the action. Can be useful for instance when using the Create Version action and just want the version without updating any issues.

Add Comment

Specify the comment to be added to the issue. Every separate lines with a blank line to separate lines into paragraphs.

Expression Values can be used here.

Create Issue

Project

Start typing the name of the project where the issue should be created in, and the options matching your text will appear.

Issue Type

Selectable issue types will become available once you have selected a project.

Summary

Provide the summary for the issue.

Expression Values can be used here, e.g. Build [[build.displayName]] was not successful.

Description

Optionally provide the description for the new issue. Every separate lines with a blank line to separate lines into paragraphs.

Expression Values can be used here.

Advanced Fields

Advanced Fields is available under Advanced Options and allows you to change issue field values even if the field is not supported by this app.

Using the feature requires that you specify the field operations using the JSON format specified by the Jira REST API which contains two attributes namely fields and update.

{
  "fields": {
    "summary": "Build [[build.displayName]] was not successful"
  },
  "update": {
    "components": [{
      "add": [{ "id": "10000" }]
    }]
  }
}

Expression Values can be used here.

Refer to the Jira Field input formats documentation for samples of different field types that can be used in this advanced fields JSON format.

Operations for the same field cannot co-exist in both fields and update sections of the JSON.

fields vs. update

fields is a shortcut for the update set operation. Take the following JSON snippet.

{
  "fields": {
    "summary": "Build [[build.displayName]] was not successful"
  }
}

The summary can also be set using the update operation below.

{
  "update": {
    "summary": [{
      "set": "Build [[build.displayName]] was not successful"
    }]
  }
}

update can be useful when you want to add or remove a value from the field, or when you want to combine operations.

For example, lets say you want to update the field components by removing one component and adding two others, take the following snippet:

{
  "update": {
    "components": [
      {
        "remove": [{ "id": "10100" }]
      }, {
        "add": [{ "id": "10101" }, { "name": "Backend" }]
      }
    ]
  }
}

On line 5 we remove the component with the id 10100 and on line 7 we add two components, one via its id namely 10101, and one via its name namely Backend.

Simpler is often better

When you want to simply set the value of a field, then prefer using the fields section of JSON, only opting for update when you want to use another operation like add, remove or edit. This will keep your JSON easier on the eyes.

Editable Issue Fields

Only fields that are on the appropriate action screen, like create, edit, transition, can be edited through a Jenkins Integration for Jira rule. If you specify a field that is not on the appropriate screen related to the action you are trying to execute, then the rule execution will fail with the reason for this will be shown in the rule log.

A good visual way to check if a rule can update a field is by opening the action yourself in Jira, e.g. to check if field ABC can be set when creating a bug in project XYZ, simply open the create issue screen in Jira for project XYZ and set the issue type to bug. Then if the field ABC is selectable on the screen then you can also set this via a rule.

An alternative method to check if the field in on the screen is to validate this through interpreting the JSON response from one of the following REST API’s:

For creating an issue: http(s)://[YOUR.INSTANCE.ROOT]/rest/api/3/issue/createmeta?expand=projects.issuetypes.fields, use the URL parameters projectKeys and issuetypeNames to limit the scope of the response and only return the fields for the specific issue type of the specific project you are interested in.
For editing an issue: http(s)://[YOUR_INSTANCE_ROOT]/rest/api/3/issue/[ISSUE_KEY]/editmeta
For transitioning an issue: http(s)://[YOUR_INSTANCE_ROOT]/rest/api/3/issue/[ISSUE_KEY]/transitions?expands=transitions.fields, you will need to lookup the transition you want to inspect, if you know the transition id, then you can use this with the URL parameter transitionId.

Create Version

Project

Start typing the name of the project where the issue should be created in, and the options matching your text will appear.

Name

Provide the name of the new version.

Expression Values can be used here, e.g. server-[[build.number]].

Description

Optionally provide the description for the new version.

Expression Values can be used here.

Start Date

Optionally provide the start date, in format yyyy-MM-dd, for the new version.

Expression Values can be used here.

Release Date

Optionally provide the release date, in format yyyy-MM-dd, for the new version.

Expression Values can be used here, e.g. [[event.timestamp]]

Released

Optionally select whether the new version should be marked as released.

Issue Selector

Select the selection method used to select the issues to add the comment on.

Linked to Build

Select this method to select all the issues that are linked to the build that was synchronized. Refer to the Data Synchronization documentation on how builds are linked to issues.

This method is only available in combination with the Build Synchronized event.

Linked to Job

This method is only available in combination with either the Job Synchronized or the Build Synchronized events.

From Expression

Select this method if you want to limit issue selection to specific attributes of the trigger event or even a static value.

JQL

None

Select this method if you don’t want to select any issues for the action. Can be useful for instance when using the Create Version action and just want the version without updating any issues.

Edit Issue

Summary

Provide the summary for the issue.

Expression Values can be used here, e.g. Build [[build.displayName]] was not successful.

Description

Optionally provide the description for the new issue. Every separate lines with a blank line to separate lines into paragraphs.

Expression Values can be used here.

Advanced Fields

Advanced Fields is available under Advanced Options and allows you to change issue field values even if the field is not supported by this app.

Using the feature requires that you specify the field operations using the JSON format specified by the Jira REST API which contains two attributes namely fields and update.

{
  "fields": {
    "summary": "Build [[build.displayName]] was not successful"
  },
  "update": {
    "components": [{
      "add": [{ "id": "10000" }]
    }]
  }
}

Expression Values can be used here.

Refer to the Jira Field input formats documentation for samples of different field types that can be used in this advanced fields JSON format.

Operations for the same field cannot co-exist in both fields and update sections of the JSON.

fields vs. update

fields is a shortcut for the update set operation. Take the following JSON snippet.

{
  "fields": {
    "summary": "Build [[build.displayName]] was not successful"
  }
}

The summary can also be set using the update operation below.

{
  "update": {
    "summary": [{
      "set": "Build [[build.displayName]] was not successful"
    }]
  }
}

update can be useful when you want to add or remove a value from the field, or when you want to combine operations.

For example, lets say you want to update the field components by removing one component and adding two others, take the following snippet:

{
  "update": {
    "components": [
      {
        "remove": [{ "id": "10100" }]
      }, {
        "add": [{ "id": "10101" }, { "name": "Backend" }]
      }
    ]
  }
}

On line 5 we remove the component with the id 10100 and on line 7 we add two components, one via its id namely 10101, and one via its name namely Backend.

Simpler is often better

Editable Issue Fields

An alternative method to check if the field in on the screen is to validate this through interpreting the JSON response from one of the following REST API’s:

For creating an issue: http(s)://[YOUR.INSTANCE.ROOT]/rest/api/3/issue/createmeta?expand=projects.issuetypes.fields, use the URL parameters projectKeys and issuetypeNames to limit the scope of the response and only return the fields for the specific issue type of the specific project you are interested in.
For editing an issue: http(s)://[YOUR_INSTANCE_ROOT]/rest/api/3/issue/[ISSUE_KEY]/editmeta
For transitioning an issue: http(s)://[YOUR_INSTANCE_ROOT]/rest/api/3/issue/[ISSUE_KEY]/transitions?expands=transitions.fields, you will need to lookup the transition you want to inspect, if you know the transition id, then you can use this with the URL parameter transitionId.

Transition Issue

Target status

Select the status the issue should be transitioned too.

Transition Pattern

When there are multiple transitions in a workflow that go to the same status, then you can use this regex pattern to select the correct transition.

Let’s say you want to transition an issue to the Done status, and let’s assume that you have a workflow that has two transition to the Done status, one named Accepted and one named Rejected. You can then use this field to select the transition you want to use, for instance to use the Accepted transition you could specify the following pattern ^Accepted$ to match the complete transition name or ^Acc(.*)$ to match the transition of which the name starts with Acc.

Issue Selector

Select the selection method used to select the issues to add the comment on.

Linked to Build

Select this method to select all the issues that are linked to the build that was synchronized. Refer to the Data Synchronization documentation on how builds are linked to issues.

This method is only available in combination with the Build Synchronized event.

Linked to Job

This method is only available in combination with either the Job Synchronized or the Build Synchronized events.

From Expression

Select this method if you want to limit issue selection to specific attributes of the trigger event or even a static value.

JQL

None

Select this method if you don’t want to select any issues for the action. Can be useful for instance when using the Create Version action and just want the version without updating any issues.

Add Comment

Specify the comment to be added to the issue. Every separate lines with a blank line to separate lines into paragraphs.

Expression Values can be used here.

Advanced Fields

Advanced Fields is available under Advanced Options and allows you to change issue field values even if the field is not supported by this app.

Using the feature requires that you specify the field operations using the JSON format specified by the Jira REST API which contains two attributes namely fields and update.

{
  "fields": {
    "summary": "Build [[build.displayName]] was not successful"
  },
  "update": {
    "components": [{
      "add": [{ "id": "10000" }]
    }]
  }
}

Expression Values can be used here.

Refer to the Jira Field input formats documentation for samples of different field types that can be used in this advanced fields JSON format.

Operations for the same field cannot co-exist in both fields and update sections of the JSON.

fields vs. update

fields is a shortcut for the update set operation. Take the following JSON snippet.

{
  "fields": {
    "summary": "Build [[build.displayName]] was not successful"
  }
}

The summary can also be set using the update operation below.

{
  "update": {
    "summary": [{
      "set": "Build [[build.displayName]] was not successful"
    }]
  }
}

update can be useful when you want to add or remove a value from the field, or when you want to combine operations.

For example, lets say you want to update the field components by removing one component and adding two others, take the following snippet:

{
  "update": {
    "components": [
      {
        "remove": [{ "id": "10100" }]
      }, {
        "add": [{ "id": "10101" }, { "name": "Backend" }]
      }
    ]
  }
}

On line 5 we remove the component with the id 10100 and on line 7 we add two components, one via its id namely 10101, and one via its name namely Backend.

Simpler is often better

Editable Issue Fields

An alternative method to check if the field in on the screen is to validate this through interpreting the JSON response from one of the following REST API’s:

For creating an issue: http(s)://[YOUR.INSTANCE.ROOT]/rest/api/3/issue/createmeta?expand=projects.issuetypes.fields, use the URL parameters projectKeys and issuetypeNames to limit the scope of the response and only return the fields for the specific issue type of the specific project you are interested in.
For editing an issue: http(s)://[YOUR_INSTANCE_ROOT]/rest/api/3/issue/[ISSUE_KEY]/editmeta
For transitioning an issue: http(s)://[YOUR_INSTANCE_ROOT]/rest/api/3/issue/[ISSUE_KEY]/transitions?expands=transitions.fields, you will need to lookup the transition you want to inspect, if you know the transition id, then you can use this with the URL parameter transitionId.

Previous: Conditions
Next: Use case: Create issue for failing builds

Didn’t find what you were looking for?

Open a ticket Contact Us