packy / jira-rest-class Goto Github PK

Hi Packy!

It's me again. I've spend some time profiling a little CLI app I made to interact with our JIRA instance at work, trying to make it faster. If you're interested, here is what I found so far:

1. This is a big one. Whenever an instance of JIRA::REST::Class::Issue is created, init() will create a method per issue type like is_bug() or is_story(). But to be able to do this, it needs to query JIRA for a list of all issue types (i.e. it will call $jira->issue_types). Although this is done only once, this call will cost some 500 ms which gives me a noticeable delay. Since all those is_$foo methods aren't even documented, I suggest making this either optional or completely getting rid of it.

2. This can be a big one. JIRA::REST::Class::Mixins::JIRA_REST() gets called quite often. In most cases, this will in turn call JIRA::REST->new(). Now, I use JIRA::REST's ability to load my jira credentials from ~/.jira. If I gpg-encrypt that file like a good employee, all the calls to JIRA::REST->new() result in one gpg decryption per call. My little script takes approximately 1s with a plain text .jira file and 18 s(!) with an encrypted one. Hacking JIRA::REST::Class::Mixins::JIRA_REST() so that it caches the JIRA::REST instance in a package variable, encrypting the file gives me almost no performance penalty.

Please let me know if you want a pull request or two. Or if you have better ideas that tackle those problems.

Cheers,
Manni

JIRA::REST::Class::Issue->add_subtask() is currently hardcoded to use issue type ID 8.

I should accept a parameter that's either the name of an issue type, an issue type ID, or an issue type object. If no parameter is passed, I should query the project to find out what subtask types there are, and if there's only one, use that. If there aren't any, or there are more than one, I should throw an exception.

Tracked as JRC-2 on my personal JIRA server.

Docs refer to SSL_verify_none but the version I just installed is using the lowercase ssl_verify_none

Sometimes if one access public JIRA API he does it anonymously, without credentials being added. Looks like JIRA-REST-Class implies a credentials should be set?

Hi Packy!

Don't want to bother you, but I would very much appreciate a new cpan release. I'm trying to get my coworkers to use a little tool I built and currently, I have to ship a patched version of JIRA::REST::Class::Factory.

I have a file $HOME/.jira containing my jira credentials.
I (successfully) use JIRA::REST::Class to access my JIRA instance.
But when calling the username accessor, it will simply return undef.
Looking at the code, I'm not sure how the username field is supposed to be populated when Config::Identity is used.

I noticed that you updated this module and tried to install the updates, but cpanm said I was up to date with version 0.03.
It seems that cpan doesn't support this:
use JIRA::REST::Class::Version qw( $VERSION );
See also http://www.cpan.org/modules/04pause.html#version