Can Bamboo change status of tickets in JIRA

Question

We have a Bamboo environment set up with JIRA integration.

Whenever a developer commits a fixed issue to git, he notes the issue number in the commit message, and indeed I can see the proper link for that issue in Bamboo, which leads into the ticket in JIRA.

I was wondering - is there a way for Bamboo to automate setting the ticket status of every ticket committed to the build to "Ready for QA"?

So for instance, if I start a new build which has a commit of ISSUE-123 in JIRA, Bamboo will set ISSUE-123 status to "Ready for QA"?

Answer 1

Yes, Bamboo can change status of tickets in JIRA. But you will need to do a little bit of magic.

First of all, you need to learn how to use CLI plugin for JIRA. It is a great tool (it is worth mentioning that it has become a winner of atlassian codegeist contest in 2010) for the purpose of automating routine JIRA-related tasks. Actually, there are few versions of this tool that allow automating almost all Atlassian tools (JIRA, Confluence, Bamboo, Crucible, Fisheye, Stash) via command line scripting. Even though it is a little bit slow, it can do pretty much everything including issue status change. Please note it could be used both as a JIRA plugin and as a standalone command line tool. You need to install standalone version of JIRA CLI plugin (here is installation guide) on the machine where your Bamboo build agent is run.

In order to fast track an issue (that is how atlassian developers call the process of changing issue statuses automatically) in JIRA, you will need to use following command:

java -jar jira-cli-3.3.0.jar --action progressIssue --issue ISSUE-123 --step WORKFLOW_TRANSITION_ID --user USERNAME --password PASSWORD --server http://yourjira.company.com 

Replace template option values with your actual values. Important value is WORKFLOW_TRANSITION_ID as long as it specifies which workflow transition will be used in order to transfer your JIRA issue into the status you actually need. In order to find WORKFLOW_TRANSITION_ID, you need to check workflow that is used for the ISSUE-123. Usually, you are about to fast track issues that have the same issue type (for example, Bug, Enhancement, etc). Also, usually issues with the same issue type have the same workflow (for example, Bug workflow).

You need to get to the administrative section of JIRA and find that workflow. Then you need to find out ids of all transitions that lead to the status you want issue to have after your update. In your case you need to find 'Ready for QA' status and all its incoming transitions. Write down ids of those transitions and use them later in order to substitute WORKFLOW_TRANSITION_ID value in the template.

If you have transitions with ids 51, 62 and 83, then your script will look as follows:

java -jar jira-cli-3.3.0.jar --action progressIssue --issue ISSUE-123 --step 51 --user USERNAME --password PASSWORD --server http://yourjira.company.com
java -jar jira-cli-3.3.0.jar --action progressIssue --issue ISSUE-123 --step 62 --user USERNAME --password PASSWORD --server http://yourjira.company.com
java -jar jira-cli-3.3.0.jar --action progressIssue --issue ISSUE-123 --step 83 --user USERNAME --password PASSWORD --server http://yourjira.company.com

If you need to fast track issues with other issue types and, therefore, workflows, you will need to find those workflows and find transitions that leads to 'Ready for QA' status (if it is actually used by workflow) just like you did with previous workflow.

In case you are confused with all the available command line options and their values, use JIRA CLI documentation as a command line options reference.

After you have figured out the content of the script that is going to fast track issues to the required status (in your case 'Ready for QA'), you will need to include it into the build script used by Bamboo.

Next step would be to store content of fast tracking script to the file:

Bash (build.sh):

while getopts "j:" opt; do
  case $opt in
    j)
      java -jar jira-cli-3.3.0.jar --action progressIssue --issue $OPTARG --step 51 --user USERNAME --password PASSWORD --server http://yourjira.company.com
      java -jar jira-cli-3.3.0.jar --action progressIssue --issue $OPTARG --step 62 --user USERNAME --password PASSWORD --server http://yourjira.company.com
      java -jar jira-cli-3.3.0.jar --action progressIssue --issue $OPTARG --step 83 --user USERNAME --password PASSWORD --server http://yourjira.company.com
      ;;
    \?)
      echo "No issue key has been passed: -$OPTARG" >&2
      ;;
  esac
done

Note that it uses -j option in order to specify JIRA issue key for the script as a command line argument.

Everything else depends on what build management tool you use (Ant, Maven or just plain bash). But, in any case, you will be able to pass jira key (that bamboo gets for you from the git comment) as a command line option for the build script you use on Bamboo:

Bash:

./build.sh -j ${bamboo.issueKey} 

Ant:

ant -Djirakey=${bamboo.issueKey}

Maven:

mvn -Djirakey=${bamboo.issueKey}

Last step you need is to adapt fast track code for the build management tool you use.

Ant (build.xml):

<exec executable="bash" dir=".">
   <arg value="build.sh"/>
   <arg value="-j"/>
   <arg value="${jirakey}"/>
</exec>

For Maven it is much more complex. Use maven exec plugin for executing build.sh from your build script.

In order to avoid writing complex build scripts, you might choose to add standalone build step on Bamboo that will be run after successful build. But in this case you will not be able to update issue status while build is still running (actually, not sure, you want to do that). Usually adding standalone build step is enough to achieve what you want. Just put ./build.sh -j ${bamboo.issueKey} in the field 'Argument' while adding new build step on Bamboo.

NOTE: I didn't test any of those scripts because currently I do not have bamboo installed and do not have chance to experiment with fast tracking by CI server. So, be careful and make sure you understand what you are doing.

Hope my recommendations will help you to achieve what you want. Good luck!

Answer 2

I know there's already an answer accepted, and it is the correct answer indeed.

What I think is missing from Atlassian CLI is a proper Homebrew formula to install the tools on OSX.

Here's the formula that I use.

#

require 'formula'

# Homebrew formula to install atlassian CLI tools

class NewsAtlassianCli < Formula

    version "3.6.0"

    homepage 'https://marketplace.atlassian.com/plugins/org.swift.atlassian.cli'
    url 'https://marketplace.atlassian.com/download/plugins/org.swift.atlassian.cli/version/360'
    sha1 'a56aed6b6fe19a3b59998f9aed8da0077bc9d441'

    # dependencies (if any)

    # Install
    def install

        # this is garbage
        puts "Cleaning up windows stuff and examples..."
        rm Dir["*.bat"]
        rm_rf "examples"

        # patch and move
        puts "Patching shell scripts and moving them to bin..."
        # patch by updating path to lib folder
        Dir['*.sh'].each do |f|
            system "sed -i -e 's,/lib,/../lib,g' #{f}"
        end

        # move the all to bin
        Dir.mkdir "bin"
        Dir['*.sh'].each { |f| mv f, "bin/atlas-#{f.sub('.sh', '')}" }

        prefix.install_metafiles
        prefix.install Dir['*']
    end

    test do
        puts "version: #{version}"
    end
end

As you can see, it cleans up all Windows noise and examples.

Then it fixes the folder structure. All the toolsets normally have bin, lib and other folders. Homebrew then creates links in /usr/local/bin, */usr/local/lib and so on.

Atlassian ignore this rule for reasons that I don't quite know, so the tools won't properly install.

One way to fix it is to move all executables to bin folder, and patch them by prelacing all references to lib/... with ../lib/....

I also decided to drop the .sh and prepend all executables with atlas-, since atlas-all is much better than all or all.sh.

I'm still toying with an idea to contribute this formula to Homebrew.