gump-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Jack" <aj...@mric.coop>
Subject Gump3 and JIRA
Date Thu, 26 May 2005 15:37:09 GMT
Folks,

I am starting to think that Gump3 needs to integrate with JIRA, in
preference to building some functionality itself. Basically, Gump3 ought
leverage JIRA's notification ability (e-mail and RSS),  and it's tracking
process (commenting, tracking, status, history). Basically Gump outages
(other than software bugs in Gump) ought be treated as JIRA issues like any
other.

I like this idea because we are leveraging what exists, rather than
re-inventing the wheel, and (in theory) we are putting information where
information ought reside. My belief is that if we had a documented record of
Gump outages and fixes we'd have accumulate some awesome exchanges. [We've
tried doing that on the Gump blog (which died w/ Brutus, I think), but that
is gathered from folks memory of exchanges. Much nicer if we could record as
we go.] I don't know how good JIRA is for historical queries, looking for
hot spots, or trouble areas, but I'd have to assume that is something they'd
do better than we.

I did a quick look for ways to talk to JIRA, and I see they have a
WebServices API (built using AXIS). I've not tried it, but I can't imagine
that Python couldn't talk to JIRA quite easily, and with WebServices it
ought (hopefully) be able to exchange issue identifiers (etc) when an issue
is created.

For example, if Gump3 could (upon build failure) check if there exists, for
that project, an (open) issue in JIRA, that was create by Gump, then it'd do
nothing. If not, it'd create an issue and store the issue identifier for
later. Gump could add build outputs as attachments, and so forth.

I've not read the WSDL sufficient to know this is all doable, but it looks a
rich interface.

WSDL: http://jira.atlassian.com/rpc/soap/jirasoapservice-v2?wsdl

Some considerations ...

1) Clearly JIRA doesn't cover all the projects we interact with. If we chose
to go this route, perhaps we could create a project for Gump-Issues for
non-JIRA projects.

2) I don't know how JIRA works across projects, but (say) project A fails to
build and a human (or one day code) determines that the root cause was
dependent project B. Could a project A JIRA issue be assigned to B, or
somehow closed w/ reason being the new B issue? I'd like to be able (over
time) to really track the impact of outages/incompatibilities.

3) Security. I don't know what authentication mechanism it uses, or if
infra@ would allow this to be enabled. (Unfortunately this isn't enabled on
Apache today.) Further, I don't know if connectivity from vmgump (an
untrusted location) would be allowed (although SMTP connectivity has been.)

Apache JIRA: http://issues.apache.org/jira/rpc/soap/jirasoapservice-v2?wsdl

Integration has some downsides, but I wonder if it is the right thing to do
for keeping Gump3 simple, for the greater ASF community, and for leveraging
others. Thoughts?

regards,

Adam


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org


Mime
View raw message