Jira Plugin Problems

[Rob Oxspring]

Hi all,

We've been using the Jira plugin with hudson for some time and have  
hit a number of problems.  We have a single subversion trunk that is  
used to build a number of different products and have a separate  
hudson job and Jira project for each product.  Some of the problems  
we're seeing are probably simply due to our structure, some appear to  
just be bugs. I figured it would be worth while soliciting thoughts  
and ideas here before I consider raising issues on java.net.

When we make a change and reference an issue AAA-123, hudson notices  
this in the next build of AAA and comments on the integration in the  
AAA-123 issue.  Later hudson builds BBB and notices AAA-123 in the svn  
history and so AAA-123 gets commented about its integration into BBB.  
While this latter comment is technically correct we're not really  
interested since its not a BBB issue.  It would be helpful to us if we  
could link hudson Jobs to Jira project IDs so that the integration  
commented on just the issues that match the job.

We also have a possibly related problem where a single commit  
referencing AAA-123 will cause several of the subsequent AAA builds  
each commenting the integration in the Jira issue.  Both this and the  
previous issue result in an awful lot of comment spam in Jira.  If  
anyone can make sense of what's happening here I'd be grateful for an  
explanation!

Hudson jobs are failed everytime hudson fails to comment on an issue,  
this causes confusion and concern to our team as otherwise usable  
builds are labelled as a failure.  Too often this can be traced down  
to people mistyping an issue id (aaa-123, AAA123) and occasionally  
accidentally entering a non-existent issue (AGE1-23, AGE-321).  As far  
as we can tell there seem to be a lot of other occasions where Jira  
rejects valid issue ids and as with the typos etc the problem is shown  
up as a RemotePermissionException with no indication of which Jira ID  
was attempted.  It would be great if it were easier to identify the  
cause of such issues, and I'm not really sure that this should cause  
the build to be labelled a failure.

After thinking about the above problems, today we decided to clear the  
jira username/password within hudson so that integration comments are  
not attempted anymore.  Hopefully this will allow us to duck the  
artificial failures and the comment spam completely for now.  
Unfortunately this had the result that the build job no longer links  
through to the Jira issue as I'm pretty sure it used to.  Where the  
issue id AAA-123 would previously be a link to the corresponding issue  
within Jira, now it is displayed as unclickable text.  This seems like  
an unnecessary restriction as those links were still useful to us and  
shouldn't need a jira login to work.

Hopefully all that makes sense, I'll be happy to clarify or expand if  
necessary!

Thanks in advance,

Rob


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[kohsuke]

Robert Oxspring wrote:
> Hi all,
>
> We've been using the Jira plugin with hudson for some time and have  
> hit a number of problems.  We have a single subversion trunk that is  
> used to build a number of different products and have a separate  
> hudson job and Jira project for each product.  Some of the problems  
> we're seeing are probably simply due to our structure, some appear to  
> just be bugs. I figured it would be worth while soliciting thoughts  
> and ideas here before I consider raising issues on java.net.

Thanks.


> When we make a change and reference an issue AAA-123, hudson notices  
> this in the next build of AAA and comments on the integration in the  
> AAA-123 issue.  Later hudson builds BBB and notices AAA-123 in the svn  
> history and so AAA-123 gets commented about its integration into BBB.  
> While this latter comment is technically correct we're not really  
> interested since its not a BBB issue.  It would be helpful to us if we  
> could link hudson Jobs to Jira project IDs so that the integration  
> commented on just the issues that match the job.

This is strange. Does the fix to AAA-123 touch some of the files that
would be then checked out by the BBB job? If not, I don't see how
AAA-123 would be associated with a build of BBB.


> We also have a possibly related problem where a single commit  
> referencing AAA-123 will cause several of the subsequent AAA builds  
> each commenting the integration in the Jira issue.  Both this and the  
> previous issue result in an awful lot of comment spam in Jira.  If  
> anyone can make sense of what's happening here I'd be grateful for an  
> explanation!

When those multiple builds of AAA happen, what do they list as their
changes? Do they have the same changes listed over and over again? I
think more examples would be helpful.

> Hudson jobs are failed everytime hudson fails to comment on an issue,  
> this causes confusion and concern to our team as otherwise usable  
> builds are labelled as a failure.  Too often this can be traced down  
> to people mistyping an issue id (aaa-123, AAA123) and occasionally  
> accidentally entering a non-existent issue (AGE1-23, AGE-321).  As far  
> as we can tell there seem to be a lot of other occasions where Jira  
> rejects valid issue ids and as with the typos etc the problem is shown  
> up as a RemotePermissionException with no indication of which Jira ID  
> was attempted.  It would be great if it were easier to identify the  
> cause of such issues, and I'm not really sure that this should cause  
> the build to be labelled a failure.

Can you share some of those stack traces? The error message / error code
might help us improve Hudson to handle them more gracefully.

Or maybe we should just ignore all exceptions from JIRA? But that might
then mask some configuration problems?

> After thinking about the above problems, today we decided to clear the  
> jira username/password within hudson so that integration comments are  
> not attempted anymore.  Hopefully this will allow us to duck the  
> artificial failures and the comment spam completely for now.  
> Unfortunately this had the result that the build job no longer links  
> through to the Jira issue as I'm pretty sure it used to.  Where the  
> issue id AAA-123 would previously be a link to the corresponding issue  
> within Jira, now it is displayed as unclickable text.  This seems like  
> an unnecessary restriction as those links were still useful to us and  
> shouldn't need a jira login to work.

Unfortunately JIRA requires a login even if Hudson is just reading data
--- like checking what keys are valid project names. So that's why
currently even a seemingly read-only feature relies on the valid login.

Two comments on this --- you can tell Hudson not to update issues from
the job configuration, even when you have a valid login. So you should
be able to do that to get the links back. Also, Hudson should be able to
make a reasonable guess at the JIRA issue ID format even when it can't
talk to the server. Please consider filing an issue on this point.

>
> Hopefully all that makes sense, I'll be happy to clarify or expand if  
> necessary!
>
> Thanks in advance,
>
> Rob
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Kohsuke Kawaguchi
Sun Microsystems                   kohsuke.kawaguchi@...

[Rob Oxspring]

Sorry for the delay, your reply got misfiltered.

On 8 Jul 2008, at 00:38, Kohsuke Kawaguchi wrote:

> Robert Oxspring wrote:
>> Hi all,
>> We've been using the Jira plugin with hudson for some time and  
>> have  hit a number of problems.  We have a single subversion trunk  
>> that is  used to build a number of different products and have a  
>> separate  hudson job and Jira project for each product.  Some of  
>> the problems  we're seeing are probably simply due to our  
>> structure, some appear to  just be bugs. I figured it would be  
>> worth while soliciting thoughts  and ideas here before I consider  
>> raising issues on java.net.
>
> Thanks.
>
>
>> When we make a change and reference an issue AAA-123, hudson  
>> notices  this in the next build of AAA and comments on the  
>> integration in the  AAA-123 issue.  Later hudson builds BBB and  
>> notices AAA-123 in the svn  history and so AAA-123 gets commented  
>> about its integration into BBB.   While this latter comment is  
>> technically correct we're not really  interested since its not a  
>> BBB issue.  It would be helpful to us if we  could link hudson Jobs  
>> to Jira project IDs so that the integration  commented on just the  
>> issues that match the job.
>
> This is strange. Does the fix to AAA-123 touch some of the files  
> that would be then checked out by the BBB job? If not, I don't see  
> how AAA-123 would be associated with a build of BBB.

That's correct, since we have a single trunk for the entire suite then  
the codebase for AAA overlaps heavily with that of BBB.

>
>
>
>> We also have a possibly related problem where a single commit  
>> referencing AAA-123 will cause several of the subsequent AAA  
>> builds  each commenting the integration in the Jira issue.  Both  
>> this and the  previous issue result in an awful lot of comment spam  
>> in Jira.  If  anyone can make sense of what's happening here I'd be  
>> grateful for an  explanation!
>
> When those multiple builds of AAA happen, what do they list as their  
> changes? Do they have the same changes listed over and over again? I  
> think more examples would be helpful.

I'll try and look back into our build history and see if I can isolate  
some examples to pick through.  I failed to mention that this was an  
intermittent issue so examples aren't immediately to hand.

>
>
>
>
>> Hudson jobs are failed everytime hudson fails to comment on an  
>> issue,  this causes confusion and concern to our team as otherwise  
>> usable  builds are labelled as a failure.  Too often this can be  
>> traced down  to people mistyping an issue id (aaa-123, AAA123) and  
>> occasionally  accidentally entering a non-existent issue (AGE1-23,  
>> AGE-321).  As far  as we can tell there seem to be a lot of other  
>> occasions where Jira  rejects valid issue ids and as with the typos  
>> etc the problem is shown  up as a RemotePermissionException with no  
>> indication of which Jira ID  was attempted.  It would be great if  
>> it were easier to identify the  cause of such issues, and I'm not  
>> really sure that this should cause  the build to be labelled a  
>> failure.
>
> Can you share some of those stack traces? The error message / error  
> code might help us improve Hudson to handle them more gracefully.

I'll aim to pull some out when I'm in the office tomorrow and pass  
them on.  Am a big fan of Hudson's graceful and helpful error handling  
btw.

>
>
> Or maybe we should just ignore all exceptions from JIRA? But that  
> might then mask some configuration problems?

Yeah, that's a difficult one.  I'm sure people wouldn't want to ignore  
the configuration errors; and adding a failonerror config option could  
be considered overkill.  I wonder if there might be some way of adding  
the error to some central hudson online error log and have it kept  
separate from the build specific logs that cause a build to be marked  
as a failure.

>
>
>
>> After thinking about the above problems, today we decided to clear  
>> the  jira username/password within hudson so that integration  
>> comments are  not attempted anymore.  Hopefully this will allow us  
>> to duck the  artificial failures and the comment spam completely  
>> for now.   Unfortunately this had the result that the build job no  
>> longer links  through to the Jira issue as I'm pretty sure it used  
>> to.  Where the  issue id AAA-123 would previously be a link to the  
>> corresponding issue  within Jira, now it is displayed as  
>> unclickable text.  This seems like  an unnecessary restriction as  
>> those links were still useful to us and  shouldn't need a jira  
>> login to work.
>
> Unfortunately JIRA requires a login even if Hudson is just reading  
> data --- like checking what keys are valid project names. So that's  
> why currently even a seemingly read-only feature relies on the valid  
> login.
>
> Two comments on this --- you can tell Hudson not to update issues  
> from the job configuration, even when you have a valid login. So you  
> should be able to do that to get the links back.

Hmmmm, I saw that option in the past but didn't spot it on this  
occasion - I figured it must be keying off the presence of login  
details.  I'll give this a try.


> Also, Hudson should be able to make a reasonable guess at the JIRA  
> issue ID format even when it can't talk to the server. Please  
> consider filing an issue on this point.

Yeah - this is exactly how I supposed it would work.  Will raise the  
issue.

Thanks,

Rob

>
>
>
>> Hopefully all that makes sense, I'll be happy to clarify or expand  
>> if  necessary!
>> Thanks in advance,
>> Rob
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                   kohsuke.kawaguchi@...

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Rob Oxspring]

Whoa, seems like this one slipped off my radar.  Sorry.  Comments
inline.

On Mon, 07 Jul 2008 16:38:16 -0700, "Kohsuke Kawaguchi"
<Kohsuke.Kawaguchi@...> said:

> Robert Oxspring wrote:
> > Hi all,
> >
> > We've been using the Jira plugin with hudson for some time and have  
> > hit a number of problems.  We have a single subversion trunk that is  
> > used to build a number of different products and have a separate  
> > hudson job and Jira project for each product.  Some of the problems  
> > we're seeing are probably simply due to our structure, some appear to  
> > just be bugs. I figured it would be worth while soliciting thoughts  
> > and ideas here before I consider raising issues on java.net.
>
> Thanks.
>
>
> > When we make a change and reference an issue AAA-123, hudson notices  
> > this in the next build of AAA and comments on the integration in the  
> > AAA-123 issue.  Later hudson builds BBB and notices AAA-123 in the svn  
> > history and so AAA-123 gets commented about its integration into BBB.  
> > While this latter comment is technically correct we're not really  
> > interested since its not a BBB issue.  It would be helpful to us if we  
> > could link hudson Jobs to Jira project IDs so that the integration  
> > commented on just the issues that match the job.
>
> This is strange. Does the fix to AAA-123 touch some of the files that
> would be then checked out by the BBB job? If not, I don't see how
> AAA-123 would be associated with a build of BBB.

Yes, we use a single svn trunk for the entire suite of products so no
matter which product is being built.  Therefore changes to ALL products
within the suite get seen in the svn logs of ALL products.  I'm aware
that this may be suboptimal but it is the best compromise of ease of
maintenance vs product / component independance.

>
>
> > We also have a possibly related problem where a single commit  
> > referencing AAA-123 will cause several of the subsequent AAA builds  
> > each commenting the integration in the Jira issue.  Both this and the  
> > previous issue result in an awful lot of comment spam in Jira.  If  
> > anyone can make sense of what's happening here I'd be grateful for an  
> > explanation!
>
> When those multiple builds of AAA happen, what do they list as their
> changes? Do they have the same changes listed over and over again? I
> think more examples would be helpful.
>

I haven't seen this particular problem for a while, maybe its gone away
with recent hudson/plugin upgrades.  I'll keep a look out and see if I
can gather concrete evidence if it crops up again.

>
>
> > Hudson jobs are failed everytime hudson fails to comment on an issue,  
> > this causes confusion and concern to our team as otherwise usable  
> > builds are labelled as a failure.  Too often this can be traced down  
> > to people mistyping an issue id (aaa-123, AAA123) and occasionally  
> > accidentally entering a non-existent issue (AGE1-23, AGE-321).  As far  
> > as we can tell there seem to be a lot of other occasions where Jira  
> > rejects valid issue ids and as with the typos etc the problem is shown  
> > up as a RemotePermissionException with no indication of which Jira ID  
> > was attempted.  It would be great if it were easier to identify the  
> > cause of such issues, and I'm not really sure that this should cause  
> > the build to be labelled a failure.
>
> Can you share some of those stack traces? The error message / error code
> might help us improve Hudson to handle them more gracefully.

Subversion commit message:
  Issue: AGE-1777 Stopped encrypting the debug log

I'm absolutely certain that the issue exists AND that hudson's user has
permission to view it, and to comment on it; but still I get the
following error failing from jira failing the build:

FATAL: null
AxisFault
 faultCode:
 {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
 faultSubcode:
 faultString:
 com.atlassian.jira.rpc.exception.RemotePermissionException: This issue
 does not exist or you don't have permission to view it.
 faultActor:
 faultNode:
 faultDetail:
        {}com.atlassian.jira.rpc.exception.RemotePermissionException:null
        {http://xml.apache.org/axis/}hostname:hb-jira

com.atlassian.jira.rpc.exception.RemotePermissionException: This issue
does not exist or you don't have permission to view it.
        at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
        at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
        at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
        at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
        at java.lang.Class.newInstance0(Class.java:355)
        at java.lang.Class.newInstance(Class.java:308)
        at org.apache.axis.encoding.ser.BeanDeserializer.<init>(BeanDeserializer.java:104)
        at org.apache.axis.encoding.ser.BeanDeserializer.<init>(BeanDeserializer.java:90)
        at hudson.plugins.jira.soap.RemotePermissionException.getDeserializer(RemotePermissionException.java:75)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.apache.axis.encoding.ser.BaseDeserializerFactory.getSpecialized(BaseDeserializerFactory.java:154)
        at org.apache.axis.encoding.ser.BaseDeserializerFactory.getDeserializerAs(BaseDeserializerFactory.java:84)
        at org.apache.axis.encoding.DeserializationContext.getDeserializer(DeserializationContext.java:464)
        at org.apache.axis.encoding.DeserializationContext.getDeserializerForType(DeserializationContext.java:547)
        at org.apache.axis.message.SOAPFaultDetailsBuilder.onStartChild(SOAPFaultDetailsBuilder.java:157)
        at org.apache.axis.encoding.DeserializationContext.startElement(DeserializationContext.java:1035)
        at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.startElement(AbstractSAXParser.java:501)
        at com.sun.org.apache.xerces.internal.parsers.AbstractXMLDocumentParser.emptyElement(AbstractXMLDocumentParser.java:179)
        at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanStartElement(XMLNSDocumentScannerImpl.java:377)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2740)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:645)
        at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140)
        at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:508)
        at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807)
        at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
        at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
        at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
        at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
        at javax.xml.parsers.SAXParser.parse(SAXParser.java:395)
        at org.apache.axis.encoding.DeserializationContext.parse(DeserializationContext.java:227)
        at org.apache.axis.SOAPPart.getAsSOAPEnvelope(SOAPPart.java:696)
        at org.apache.axis.Message.getSOAPEnvelope(Message.java:435)
        at org.apache.axis.handlers.soap.MustUnderstandChecker.invoke(MustUnderstandChecker.java:62)
        at org.apache.axis.client.AxisClient.invoke(AxisClient.java:206)
        at org.apache.axis.client.Call.invokeEngine(Call.java:2784)
        at org.apache.axis.client.Call.invoke(Call.java:2767)
        at org.apache.axis.client.Call.invoke(Call.java:2443)
        at org.apache.axis.client.Call.invoke(Call.java:2366)
        at org.apache.axis.client.Call.invoke(Call.java:1812)
        at hudson.plugins.jira.soap.JirasoapserviceV2SoapBindingStub.getIssue(JirasoapserviceV2SoapBindingStub.java:4537)
        at hudson.plugins.jira.JiraSession.getIssue(JiraSession.java:83)
        at hudson.plugins.jira.Updater.perform(Updater.java:82)
        at hudson.plugins.jira.JiraIssueUpdater.perform(JiraIssueUpdater.java:24)
        at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:309)
        at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:297)
        at hudson.model.Build$RunnerImpl.post2(Build.java:122)
        at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:282)
        at hudson.model.Run.run(Run.java:804)
        at hudson.model.Build.run(Build.java:84)
        at hudson.model.ResourceController.execute(ResourceController.java:70)
        at hudson.model.Executor.run(Executor.java:88)

I've also just seen a NPE cropping up from a build which was forced and
therefore had no reason to involve jira at all:

FATAL: null
java.lang.NullPointerException
        at hudson.model.AbstractBuild$DependencyChange.<init>(AbstractBuild.java:642)
        at hudson.model.AbstractBuild.getDependencyChanges(AbstractBuild.java:608)
        at hudson.plugins.jira.Updater.findIssueIdsRecursive(Updater.java:121)
        at hudson.plugins.jira.Updater.perform(Updater.java:47)
        at hudson.plugins.jira.JiraIssueUpdater.perform(JiraIssueUpdater.java:24)
        at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:309)
        at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:297)
        at hudson.model.Build$RunnerImpl.post2(Build.java:122)
        at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:282)
        at hudson.model.Run.run(Run.java:804)
        at hudson.model.Build.run(Build.java:84)
        at hudson.model.ResourceController.execute(ResourceController.java:70)
        at hudson.model.Executor.run(Executor.java:88)

>
> Or maybe we should just ignore all exceptions from JIRA? But that might
> then mask some configuration problems?
>
>
> > After thinking about the above problems, today we decided to clear the  
> > jira username/password within hudson so that integration comments are  
> > not attempted anymore.  Hopefully this will allow us to duck the  
> > artificial failures and the comment spam completely for now.  
> > Unfortunately this had the result that the build job no longer links  
> > through to the Jira issue as I'm pretty sure it used to.  Where the  
> > issue id AAA-123 would previously be a link to the corresponding issue  
> > within Jira, now it is displayed as unclickable text.  This seems like  
> > an unnecessary restriction as those links were still useful to us and  
> > shouldn't need a jira login to work.
>
> Unfortunately JIRA requires a login even if Hudson is just reading data
> --- like checking what keys are valid project names. So that's why
> currently even a seemingly read-only feature relies on the valid login.

Yeah - you're right.  Even though some jira installations are publicly
browsable I'd forgotten that ours is not so we'd need to use a password
anyway :)

>
> Two comments on this --- you can tell Hudson not to update issues from
> the job configuration, even when you have a valid login. So you should
> be able to do that to get the links back. Also, Hudson should be able to
> make a reasonable guess at the JIRA issue ID format even when it can't
> talk to the server. Please consider filing an issue on this point.
>

Seems that issue #1904 covers the same territory.  Commented on that one
rather than creating a new one.

Thanks for your time (and patience),

Rob


Jira Version: 3.11-#288
Hudson Version: 1.243
Hudson Jira Plugin Version: 1.12

  Rob Oxspring
  roxspring@...


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...