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
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.
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" }]
}]
}
}
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 thefields
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 parametersprojectKeys
andissuetypeNames
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 parametertransitionId
.
Next: Getting Started