VERSION

version 1.3

SYNOPSIS

use JIRA::Client::Automated;
my $jira = JIRA::Client::Automated->new($url, $user, $password);
my $jira_ua = $jira->ua(); # to add in a proxy
$jira->trace(1); # enable tracing of requests and responses
# The simplest way to create an issue
my $issue = $jira->create_issue($project, $type, $summary, $description);
# The simplest way to create a subtask
my $subtask = $jira->create_subtask($project, $summary, $description, $parent_key);
# A complex but flexible way to create a new issue, story, task or subtask
# if you know Jira issue hash structure well.
my $issue = $jira->create({
# Jira issue 'fields' hash
project => {
key => $project,
},
issuetype => {
name => $type, # "Bug", "Task", "Sub-task", etc.
},
summary => $summary,
description => $description,
parent => { # only required for a subtask
key => $parent_key,
},
...
});
my $search_results = $jira->search_issues($jql, 1, 100); # query should be a single string of JQL
my @issues = $jira->all_search_results($jql, 1000); # query should be a single string of JQL
my $issue = $jira->get_issue($key);
$jira->update_issue($key, $update_hash); # update_hash is { field => value, ... }
$jira->create_comment($key, $text);
$jira->attach_file_to_issue($key, $filename);
$jira->transition_issue($key, $transition, $transition_hash); # transition_hash is { field => value, ... }
$jira->close_issue($key, $resolve, $comment); # resolve is the resolution value
$jira->delete_issue($key);
$jira->add_issue_watchers($key, $watcher1, ......);
$jira->add_issue_labels($key, $label1, ......);

DESCRIPTION

JIRA::Client::Automated is an adapter between any automated system and JIRA's REST API. This module is explicitly designed to easily create and close issues within a JIRA instance via automated scripts.

For example, if you run nightly batch jobs, you can use JIRA::Client::Automated to have those jobs automatically create issues in JIRA for you when the script runs into errors. You can attach error log files to the issues and then they'll be waiting in someone's open issues list when they arrive at work the next day.

If you want to avoid creating the same issue more than once you can search JIRA for it first, only creating it if it doesn't exist. If it does already exist you can add a comment or a new error log to that issue.

WORKING WITH JIRA

Atlassian has made a very complete REST API for recent (> 5.0) versions of JIRA. By virtue of being complete it is also somewhat large and a little complex for the beginner. Reading their tutorials is *highly* recommended before you start making hashes to update or transition issues.

<https://developer.atlassian.com/display/JIRADEV/JIRA+REST+APIs>

This module was designed for the JIRA 5.2.11 REST API, as of March 2013, but it works fine with JIRA 6.0 as well. Your mileage may vary with future versions.

JIRA ISSUE HASH FORMAT

When you work with an issue in JIRA's REST API, it gives you a JSON file that follows this spec:

<https://developer.atlassian.com/display/JIRADEV/The+Shape+of+an+Issue+in+JIRA+REST+APIs>

JIRA::Client::Automated tries to be nice to you and not make you deal directly with JSON. When you create a new issue, you can pass in just the pieces you want and ``create_issue'' will transform them to JSON for you. The same for closing and deleting issues.

Updating and transitioning issues is more complex. Each JIRA installation will have different fields available for each issue type and transition screen and only you will know what they are. So in those cases you'll need to pass in an ``update_hash'' which will be transformed to the proper JSON by the method.

An update_hash looks like this:

    { field1 => value, field2 => value2, ...}

For example:

    {
        host_id => "example.com",
        { resolution => { name => "Resolved" } }
    }

If you do not read JIRA's documentation about their JSON format you will hurt yourself banging your head against your desk in frustration the first few times you try to use ``update_issue''. Please RTFM.

Note that even though JIRA requires JSON, JIRA::Client::Automated will helpfully translate it to and from regular hashes for you. You only pass hashes to JIRA::Client::Automated, not direct JSON.

I recommend connecting to your JIRA server and calling ``get_issue'' with a key you know exists and then dump the result. That'll get you started.

METHODS

new

    my $jira = JIRA::Client::Automated->new($url, $user, $password);

Create a new JIRA::Client::Automated object by passing in the following:

1.

URL for the JIRA server, such as ``http://example.atlassian.net/''

2.

Username to use to login to the JIRA server

3.

Password for that user

All three parameters are required. JIRA::Client::Automated must connect to the JIRA instance using some username and password. You may want to set up a special ``auto'' or ``batch'' username to use just for use by scripts.

If you are using Google Account integration, the username and password to use are the ones you set up at the very beginning of the registration process and then never used again because Google logged you in.

ua

    my $ua = $jira->ua();

Returns the LWP::UserAgent object used to connect to the JIRA instance. Typically used to setup proxies or make other customizations to the UserAgent. For example:

    my $ua = $jira->ua();
    $ua->env_proxy();
    $ua->ssl_opts(...);
    $ua->conn_cache( LWP::ConnCache->new() );

trace

    $jira->trace(1);       # enable
    $jira->trace(0);       # disable
    $trace = $jira->trace;

When tracing is enabled each request and response is logged using carp.

create

    my $issue = $jira->create({
        # Jira issue 'fields' hash
        project     => {
            key => $project,
        },
        issuetype   => {
            name => $type,      # "Bug", "Task", "SubTask", etc.
        },
        summary     => $summary,
        description => $description,
        parent      => {        # only required for a subtask
            key => $parent_key,
        },
        ...
    });

Creating a new issue, story, task, subtask, etc.

Returns a hash containing only the basic information about the new issue, or dies if there is an error. The hash looks like:

    {
        id => 24066,
        key => "TEST-57",
        self => "https://example.atlassian.net/rest/api/latest/issue/24066"
    }

See also <https://developer.atlassian.com/display/JIRADEV/JIRA+REST+API+Example+-+Create+Issue>

create_issue

    my $issue = $jira->create_issue($project, $type, $summary, $description, $fields);

Creating a new issue requires the project key, type (``Bug'', ``Task'', etc.), and a summary and description.

The optional $fields parameter can be used to pass a reference to a hash of extra fields to be set when the issue is created, which avoids the need for a separate ``update_issue'' call. For example:

    $jira->create_issue($project, $type, $summary, $description, {
        labels => [ "foo", "bar" ]
    });

This method calls ``create'' and return the same hash reference that it does.

create_subtask

    my $subtask = $jira->create_subtask($project, $summary, $description, $parent_key);
    # or with optional subtask type
    my $subtask = $jira->create_subtask($project, $summary, $description, $parent_key, 'sub-task');

Creating a subtask. If your JIRA instance does not call subtasks ``Sub-task'' or ``sub-task'', then you will need to pass in your subtask type.

This method calls ``create'' and return the same hash reference that it does.

update_issue

    $jira->update_issue($key, $field_update_hash, $update_verb_hash);

There are two ways to express the updates you want to make to an issue.

For simple changes you pass $field_update_hash as a reference to a hash of field_name => new_value pairs. For example:

    $jira->update_issue($key, { summary => $new_summary });

That works for simple fields, but there are some, like comments, that can't be updated in this way. For them you need to use $update_verb_hash.

The $update_verb_hash parameter allow you to express a series of specific operations (verbs) to be performed on each field. For example:

    $jira->update_issue($key, undef, {
        labels   => [ { remove => "test" }, { add => "another" } ],
        comments => [ { remove => { id => 10001 } } ]
    });

The two forms of update can be combined in a single call.

For more information see:

    https://developer.atlassian.com/display/JIRADEV/JIRA+REST+API+Example+-+Edit+issues
    https://developer.atlassian.com/display/JIRADEV/Updating+an+Issue+via+the+JIRA+REST+APIs

get_issue

    my $issue = $jira->get_issue($key);

Returns details for any issue, given its key. This call returns a hash containing the information for the issue in JIRA's format. See ``JIRA ISSUE HASH FORMAT'' for details.

transition_issue

    $jira->transition_issue($key, $transition);
    $jira->transition_issue($key, $transition, $update_hash);

Transitioning an issue is what happens when you click the button that says ``Resolve Issue'' or ``Start Progress'' on it. Doing this from code is harder, but JIRA::Client::Automated makes it as easy as possible.

You pass this method the issue key, the name of the transition or the target status (spacing and capitalization matter), and an optional update_hash containing any fields that you want to update.

Specifying The Transition

The provided $transition name is first matched against the available transitions for the $key issue ('Start Progress', 'Close Issue'). If there's no match then the names is matched against the available target status names ('Open', 'Closed'). You can use whichever is most appropriate. For example, in your configuration the transition names might vary between different kinds of projects but the status names might be the same. In which case scripts that are meant to work across multiple projects might prefer to use the status names.

The $transition parameter can also be specified as a reference to an array of names. In this case the first one that matches either a transition name or status name is used. This makes it easier for scripts to work across multiple kinds of projects and/or handle the migration of names by allowing current and future names to be used, so the later change in JIRA config doesn't cause any breakage.

Specifying Updates

If you have required fields on the transition screen (such as ``Resolution'' for the ``Resolve Issue'' screen), you must pass those fields in as part of the update_hash or you will get an error from the server. See ``JIRA ISSUE HASH FORMAT'' for the format of the update_hash.

(Note: it appears that in some obscure cases missing required fields may cause the transition to fail without causing an error from the server. For example a field that's required but isn't configured to appear on the transition screen.)

The $update_hash is a combination of the $field_update_hash and $update_verb_hash parameters used by the ``update_issue'' method. Like this:

    $update_hash = {
        fields => $field_update_hash,
        update => $update_verb_hash
    };

You can use it to express both simple field settings and more complex update operations. For example:

    $jira->transition_issue($key, $transition, {
        fields => { summary => $new_summary },
        update => {
            labels   => [ { remove => "test" }, { add => "another" } ],
            comments => [ { remove => { id => 10001 } } ]
        }
    });

close_issue

    $jira->close_issue($key);
    $jira->close_issue($key, $resolve);
    $jira->close_issue($key, $resolve, $comment);
    $jira->close_issue($key, $resolve, $comment, $update_hash);
    $jira->close_issue($key, $resolve, $comment, $update_hash, $operation);

Pass in the resolution reason and an optional comment to close an issue. Using this method requires that the issue is is a status where it can use the ``Close Issue'' transition (or other one, specified by $operation). If not, you will get an error from the server.

Resolution (``Fixed'', ``Won't Fix'', etc.) is only required if the issue hasn't already been resolved in an earlier transition. If you try to resolve an issue twice, you will get an error.

If you do not supply a comment, the default value is ``Issue closed by script''.

The $update_hash can be used to set or edit the values of other fields.

The $operation paramter can be used to specify the closing transition type. This can be useful when your JIRA configuration uses nonstandard or localized transition and status names, e.g.

        use utf8;
        $jira->close_issue($key, $resolve, $comment, $update_hash, "Done");

See ``transition_issue'' for more details.

This method is a wrapper for ``transition_issue''.

delete_issue

    $jira->delete_issue($key);

Deleting issues is for testing your JIRA code. In real situations you almost always want to close unwanted issues with an ``Oops!'' resolution instead.

create_comment

    $jira->create_comment($key, $text);

You may use any valid JIRA markup in comment text. (This is handy for tables of values explaining why something in the database is wrong.) Note that comments are all created by the user you used to create your JIRA::Client::Automated object, so you'll see that name often.

search_issues

    my @search_results = $jira->search_issues($jql, 1, 100, $fields);

You've used JQL before, when you did an ``Advanced Search'' in the JIRA web interface. That's the only way to search via the REST API.

This is a paged method. Pass in the starting result number and number of results per page and it will return issues a page at a time. If you know you want all of the results, you can use ``all_search_results'' instead.

Optional parameter $fields is the arrayref containing the list of fields to be returned.

This method returns a hashref containing up to five values:

1.

total => total number of results

2.

start => result number for the first result

3.

max => maximum number of results per page

4.

issues => an arrayref containing the actual found issues

5.

errors => an arrayref containing error messages

For example, to page through all results $max at a time:

    my (@all_results, $issues);
    do {
        $results = $self->search_issues($jql, $start, $max);
        if ($results->{errors}) {
            die join "\n", @{$results->{errors}};
        }
        @issues = @{$results->{issues}};
        push @all_results, @issues;
        $start += $max;
    } until (scalar(@$issues) < $max);

(Or just use ``all_search_results'' instead.)

all_search_results

    my @issues = $jira->all_search_results($jql, 1000);

Like ``search_issues'', but returns all the results as an array of issues. You can specify the maximum number to return, but no matter what, it can't return more than the value of jira.search.views.default.max for your JIRA installation.

get_issue_comments

    $jira->get_issue_comments($key);

Returns arryref of all comments to the given issue.

attach_file_to_issue

    $jira->attach_file_to_issue($key, $filename);

This method does not let you attach a comment to the issue at the same time. You'll need to call ``create_comment'' for that.

Watch out for file permissions! If the user running the script does not have permission to read the file it is trying to upload, you'll get weird errors.

make_browse_url

    my $url = $jira->make_browse_url($key);

A helper method to return the "".../browse/$key"" url for the issue. It's handy to make emails containing lists of bugs easier to create.

This just appends the key to the URL for the JIRA server so that you can click on it and go directly to that issue.

get_link_types

    my $all_link_types = $jira->get_link_types();

Get the arrayref of all possible link types.

link_issues

    $jira->link_issues($from, $to, $type);

Establish a link of the type named $type from issue key $from to issue key $to . Returns nothing on success; structure containing error messages otherwise.

add_issue_labels

    $jira->add_issue_labels($issue_key, @labels);

Adds one more more labels to the specified issue.

remove_issue_labels

    $jira->remove_issue_labels($issue_key, @labels);

Removes one more more labels from the specified issue.

add_issue_watchers

    $jira->add_issue_watchers($key, @watchers);

Adds watchers to the specified issue. Returns nothing if success; otherwise returns a structure containing error message.

get_issue_watchers

    $jira->get_issue_watchers($key);

Returns arryref of all watchers of the given issue.

assign_issue

    $jira->assign_issue($key, $assignee_name);

Assigns the issue to that person. Returns the key of the issue if it succeeds.

FAQ

Why is there no object for a JIRA issue?

Because it seemed silly. You could write such an object and give it methods to transition itself, close itself, etc., but when you are working with JIRA from batch scripts, you're never really working with just one issue at a time. And when you have a hundred of them, it's easier to not objectify them and just use JIRA::Client::Automated as a mediator. That said, if this is important to you, I wouldn't say no to a patch offering this option.

AUTHOR

Michael Friedman <[email protected]>

CREDITS

Thanks very much to:

Tim Bunce <[email protected]>

Dominique Dumont <[email protected]>

Zhuang (John) Li <[email protected]>

Ivan E. Panchenko <[email protected]>

Jose Antonio Perez Testa <[email protected]>

COPYRIGHT AND LICENSE

This software is copyright (c) 2014 by Polyvore, Inc.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.