oracular (3) JIRA::Client::Automated.3pm.gz
NAME
JIRA::Client::Automated - A JIRA REST Client for automated scripts
VERSION
version 1.9
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/cloud/jira/platform/rest/#about>
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/cloud/jira/platform/rest/#api-api-2-issue-post>
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/cloud/jira/platform/rest/#api-api-2-issue-post>
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:
L<https://developer.atlassian.com/cloud/jira/platform/rest/#api-api-2-issue-issueIdOrKey-put>
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>
Andreas Mager <amager@barracuda.com>
Mike Svendsen <msven.dev@gmail.com>
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.