Provided by: libjira-client-automated-perl_1.60-1_all 
NAME
JIRA::Client::Automated - A JIRA REST Client for automated scripts
VERSION
version 1.6
SYNOPSIS
use JIRA::Client::Automated;
my $jira = JIRA::Client::Automated->new($url, $user, $password);
# If your JIRA instance does not use username/password for authorization
my $jira = JIRA::Client::Automated->new($url);
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 6 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 if your JIRA instance uses basic authorization, for
which 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.
If you have other ways of authorization, like GSSAPI based authorization, do not provide
username or password.
my $jira = JIRA::Client::Automated->new($url);
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 parameter 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.
add_issue_worklog
$jira->add_issue_worklog($key, $worklog);
Adds a worklog to the specified issue. Returns nothing if success; otherwise returns a
structure containing error message.
Sample worklog: {
"comment" => "I did some work here.",
"started" => "2016-05-27T02:32:26.797+0000",
"timeSpentSeconds" => 12000, }
get_issue_worklogs
$jira->get_issue_worklogs($key);
Returns arryref of all worklogs of the given issue.
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.
BUGS
Please report bugs or feature requests to the author.
AUTHOR
Michael Friedman <frimicc@cpan.org>
CREDITS
Thanks very much to:
Tim Bunce <timb@cpan.org>
Dominique Dumont <ddumont@cpan.org>
Zhuang (John) Li <7humblerocks@gmail.com>
Ivan E. Panchenko <panchenko@cpan.org>
José Antonio Perez Testa <japtesta@gmail.com>
Frank Schophuizen <Frank.Schophuizen@philips.com>
Zhenyi Zhou <zhenyz@cpan.org>
Roy Lyons <Roy.Lyons@cmegroup.com>
Neil Hemingway <hemingway@cpan.org>
COPYRIGHT AND LICENSE
This software is copyright (c) 2016 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.