[JIRA] (JENKINS-56243) Jenkins GUI is slow -removing cookie fixes it (temporarily)
Title: Message Title Shevek . commented on JENKINS-56243 Re: Jenkins GUI is slow -removing cookie fixes it (temporarily) The active-directory thing is a total red herring. We are affected by this, and we do not and never have used AD. The downgrade to 2.150.1 does work. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56243) Jenkins GUI is slow -removing cookie fixes it (temporarily)
Title: Message Title Shevek . commented on JENKINS-56243 Re: Jenkins GUI is slow -removing cookie fixes it (temporarily) Wadeck Follonier We are using built in user authentication with the built in access matrix. Nothing special whatsoever. Stock install via apt. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56374) JUnitResultArchiver parsing XML in sort()->compare(), killing Jenkins
Title: Message Title Shevek . commented on JENKINS-56374 Re: JUnitResultArchiver parsing XML in sort()->compare(), killing Jenkins Attached visualvm dump of retained-object sizes showing the suites in memory. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56374) JUnitResultArchiver parsing XML in sort()->compare(), killing Jenkins
Title: Message Title Shevek . updated an issue Jenkins / JENKINS-56374 JUnitResultArchiver parsing XML in sort()->compare(), killing Jenkins Change By: Shevek . Attachment: jenkins-memory.png Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56374) JUnitResultArchiver parsing XML in sort()->compare(), killing Jenkins
Title: Message Title Shevek . updated an issue Jenkins / JENKINS-56374 JUnitResultArchiver parsing XML in sort()->compare(), killing Jenkins Change By: Shevek . Environment: LinuxJava 8Jenkins 2.150.1JUnit plugin 1.27xUnit plugin 2.3.2 Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56374) JUnitResultArchiver parsing XML in sort()->compare(), killing Jenkins
Title: Message Title Shevek . commented on JENKINS-56374 Re: JUnitResultArchiver parsing XML in sort()->compare(), killing Jenkins After the GC-storm, we get this: num #instances #bytes class name -- 1: 208769 27421360 [C 2: 208315 4999560 java.lang.String 3: 81032 2593024 java.util.HashMap$Node 4: 37398 2486496 [Ljava.lang.Object; 5: 9331 2316560 [B 6: 18857 2092720 java.lang.Class 7: 62775 2008800 java.util.concurrent.ConcurrentHashMap$Node 8: 20596 1812448 java.lang.reflect.Method 9: 12253 1242400 [Ljava.util.HashMap$Node; 10: 11491 947256 [Ljava.util.WeakHashMap$Entry; which is a lot saner, and shows that all the data held in memory was related to the memory inefficiency/leak in the reporter, and is not part of normal operation. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56374) JUnitResultArchiver parsing XML in sort()->compare(), killing Jenkins
Title: Message Title Shevek . updated an issue Jenkins / JENKINS-56374 JUnitResultArchiver parsing XML in sort()->compare(), killing Jenkins Change By: Shevek . Labels: memory-leak Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56374) JUnitResultArchiver parsing XML in sort()->compare(), killing Jenkins
Title: Message Title Shevek . commented on JENKINS-56374 Re: JUnitResultArchiver parsing XML in sort()->compare(), killing Jenkins jmap -histo:live output: num #instances #bytes class name -- 1: 2678703 2691823496 [C 2: 2678264 64278336 java.lang.String 3: 811096 58398912 hudson.tasks.junit.CaseResult 4: 319187 10213984 java.util.HashMap$Node 5: 192771 8994440 [Ljava.lang.String; 6: 42153 7186960 [Ljava.lang.Object; 7: 187092 4490208 com.thoughtworks.xstream.io.path.Path 8: 12333 2778840 [Ljava.util.HashMap$Node; 9: 18705 2075528 java.lang.Class 10: 61023 1952736 java.util.concurrent.ConcurrentHashMap$Node Where did we get 811,096 CaseResults in the heap from? They're all live objects, too. This looks like a serious memory leak. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56374) JUnitResultArchiver parsing XML in sort()->compare(), killing Jenkins
Title: Message Title Shevek . updated an issue Jenkins / JENKINS-56374 JUnitResultArchiver parsing XML in sort()->compare(), killing Jenkins Change By: Shevek . Summary: JUnitResultArchiver crazy resource inefficient parsing XML in sort()->compare() , killing Jenkins Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56374) JUnitResultArchiver crazy resource inefficient, killing Jenkins
Title: Message Title Shevek . commented on JENKINS-56374 Re: JUnitResultArchiver crazy resource inefficient, killing Jenkins Note that this is the ONLY executor running, we don't run anything else in-process, and the XML file it's failing to load is only 100Mb. Wait... are we parsing XML in the compare() routine of a sort-object? What the $BADWORD...? WAT? Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56374) JUnitResultArchiver crazy resource inefficient, killing Jenkins
Title: Message Title Shevek . commented on JENKINS-56374 Re: JUnitResultArchiver crazy resource inefficient, killing Jenkins Related stack: ``` Mar 03, 2019 10:00:07 PM hudson.tasks.junit.TestResultAction load WARNING: Failed to load /home/jenkins/jobs/XXX-pr/builds/6739/junitResult.xml java.io.IOException: Unable to read /home/jenkins/jobs/XXX-pr/builds/6739/junitResult.xml at hudson.XmlFile.read(XmlFile.java:149) at hudson.tasks.junit.TestResultAction.load(TestResultAction.java:208) at hudson.tasks.junit.TestResultAction.getResult(TestResultAction.java:138) at hudson.tasks.junit.TestResultAction.getResult(TestResultAction.java:63) at hudson.tasks.test.AbstractTestResultAction.findCorrespondingResult(AbstractTestResultAction.java:252) at hudson.tasks.test.TestResult.getPreviousResult(TestResult.java:146) at hudson.tasks.junit.SuiteResult.getPreviousResult(SuiteResult.java:416) at hudson.tasks.junit.CaseResult.getPreviousResult(CaseResult.java:479) at hudson.tasks.junit.CaseResult.freeze(CaseResult.java:641) at hudson.tasks.junit.SuiteResult.freeze(SuiteResult.java:462) at hudson.tasks.junit.TestResult.freeze(TestResult.java:748) at hudson.tasks.junit.TestResultAction.load(TestResultAction.java:213) at hudson.tasks.junit.TestResultAction.getResult(TestResultAction.java:145) at hudson.tasks.junit.TestResultAction.getResult(TestResultAction.java:63) at hudson.tasks.test.AbstractTestResultAction.findCorrespondingResult(AbstractTestResultAction.java:252) at hudson.tasks.test.TestResult.getPreviousResult(TestResult.java:146) at hudson.tasks.junit.SuiteResult.getPreviousResult(SuiteResult.java:416) at hudson.tasks.junit.CaseResult.getPreviousResult(CaseResult.java:479) at hudson.tasks.junit.CaseResult.freeze(CaseResult.java:641) at hudson.tasks.junit.SuiteResult.freeze(SuiteResult.java:462) at hudson.tasks.junit.TestResult.freeze(TestResult.java:748) at hudson.tasks.junit.TestResultAction.load(TestResultAction.java:213) at hudson.tasks.junit.TestResultAction.getResult(TestResultAction.java:138) at hudson.tasks.junit.TestResultAction.getResult(TestResultAction.java:63) at hudson.tasks.test.AbstractTestResultAction.findCorrespondingResult(AbstractTestResultAction.java:252) at hudson.tasks.test.TestResult.getPreviousResult(TestResult.java:146) at hudson.tasks.junit.SuiteResult.getPreviousResult(SuiteResult.java:416) at hudson.tasks.junit.CaseResult.getPreviousResult(CaseResult.java:479) at hudson.tasks.junit.CaseResult.freeze(CaseResult.java:641) at hudson.tasks.junit.SuiteResult.freeze(SuiteResult.java:462) at hudson.tasks.junit.TestResult.freeze(TestResult.java:748) at hudson.tasks.junit.TestResultAction.load(TestResultAction.java:213) at hudson.tasks.junit.TestResultAction.getResult(TestResultAction.java:138) at hudson.tasks.junit.TestResultAction.getResult(TestResultAction.java:63) at hudson.tasks.test.AbstractTestResultAction.findCorrespondingResult(AbstractTestResultAction.java:252) at hudson.tasks.test.TestResult.getPreviousResult(TestResult.java:146) at hudson.tasks.junit.SuiteResult.getPreviousResult(SuiteResult.java:416) at hudson.tasks.junit.CaseResult.getPreviousResult(CaseResult.java:479) at hudson.tasks.junit.CaseResult.freeze(CaseResult.java:641) at hudson.tasks.junit.SuiteResult.freeze(SuiteResult.java:462) at hudson.tasks.junit.TestResult.freeze(TestResult.java:748) at hudson.tasks.junit.TestResultAction.load(TestResultAction.java:213) at hudson.tasks.junit.TestResultAction.getResult(TestResultAction.java:138) at hudson.tasks.junit.TestResultAction.getResult(TestResultAction.java:63) at hudson.tasks.test.AbstractTestResultAction.findCorrespondingResult(AbstractTestResultAction.java:252) at
[JIRA] (JENKINS-56374) JUnitResultArchiver crazy resource inefficient, killing Jenkins
Title: Message Title Shevek . updated an issue Jenkins / JENKINS-56374 JUnitResultArchiver crazy resource inefficient, killing Jenkins Change By: Shevek . Jenkins 2.150.1Jenkins dies with the JVM going into perpetual ergonomics GC. The JVM has a 4Gb heap. The biggest XML file is 180Mb. So that's not a fundamental limitation. Something dumb is going on.I _think_ it might be repeatedly parsing the same XML file again and again, because when I dump jstack, I've seen a lot of different XML parsers there. This MIGHT be triggered by a @Parameterized junit test with 50,000 cases. In any case, this has made Jenkins totally unusable.It also dies when we have a single JUnit case with a 1Gb output XML, but we have worked around that. But we cannot reduce the size of our test suite just to keep Jenkins happy.Reported critical as this has stopped us from using Jenkins. Tempted to report blocker.Here is some stack.``` at com.thoughtworks.xstream.mapper.AnnotationMapper.processAnnotations(AnnotationMapper.java:180) at com.thoughtworks.xstream.mapper.AnnotationMapper.defaultImplementationOf(AnnotationMapper.java:141) at hudson.util.xstream.MapperDelegate.defaultImplementationOf(MapperDelegate.java:59) at com.thoughtworks.xstream.mapper.MapperWrapper.defaultImplementationOf(MapperWrapper.java:46) at hudson.util.RobustReflectionConverter.determineType(RobustReflectionConverter.java:475) at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:327) at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:270) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:65) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:50) at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:71) at hudson.util.RobustCollectionConverter.populateCollection(RobustCollectionConverter.java:85) at com.thoughtworks.xstream.converters.collections.CollectionConverter.unmarshal(CollectionConverter.java:80) at hudson.util.RobustCollectionConverter.unmarshal(RobustCollectionConverter.java:76) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:65) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66) at hudson.util.RobustReflectionConverter.unmarshalField(RobustReflectionConverter.java:393) at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:331) at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:270) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72) at
[JIRA] (JENKINS-56374) JUnitResultArchiver crazy resource inefficient, killing Jenkins
Title: Message Title Shevek . updated an issue Jenkins / JENKINS-56374 JUnitResultArchiver crazy resource inefficient, killing Jenkins Change By: Shevek . Environment: Jenkins 2.150.1Jenkins dies with the JVM going into perpetual ergonomics GC. The JVM has a 4Gb heap. The biggest XML file is 180Mb. So that's not a fundamental limitation. Something dumb is going on.I _think_ it might be repeatedly parsing the same XML file again and again, because when I dump jstack, I've seen a lot of different XML parsers there. This MIGHT be triggered by a @Parameterized junit test with 50,000 cases. In any case, this has made Jenkins totally unusable.It also dies when we have a single JUnit case with a 1Gb output XML, but we have worked around that. But we cannot reduce the size of our test suite just to keep Jenkins happy.Reported critical as this has stopped us from using Jenkins. Tempted to report blocker.Here is some stack.```at com.thoughtworks.xstream.mapper.AnnotationMapper.processAnnotations(AnnotationMapper.java:180)at com.thoughtworks.xstream.mapper.AnnotationMapper.defaultImplementationOf(AnnotationMapper.java:141)at hudson.util.xstream.MapperDelegate.defaultImplementationOf(MapperDelegate.java:59)at com.thoughtworks.xstream.mapper.MapperWrapper.defaultImplementationOf(MapperWrapper.java:46)at hudson.util.RobustReflectionConverter.determineType(RobustReflectionConverter.java:475)at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:327)at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:270)at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72)at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:65)at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66)at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:50)at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:71)at hudson.util.RobustCollectionConverter.populateCollection(RobustCollectionConverter.java:85)at com.thoughtworks.xstream.converters.collections.CollectionConverter.unmarshal(CollectionConverter.java:80)at hudson.util.RobustCollectionConverter.unmarshal(RobustCollectionConverter.java:76)at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72)at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:65)at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66)at hudson.util.RobustReflectionConverter.unmarshalField(RobustReflectionConverter.java:393)at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:331)at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:270)at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72)at
[JIRA] (JENKINS-56374) JUnitResultArchiver crazy resource inefficient, killing Jenkins
Title: Message Title Shevek . created an issue Jenkins / JENKINS-56374 JUnitResultArchiver crazy resource inefficient, killing Jenkins Issue Type: Bug Assignee: Varun Menon Components: core, junit-plugin, test-results-analyzer-plugin Created: 2019-03-03 22:07 Environment: Jenkins 2.150.1 Jenkins dies with the JVM going into perpetual ergonomics GC. The JVM has a 4Gb heap. The biggest XML file is 180Mb. So that's not a fundamental limitation. Something dumb is going on. I _think_ it might be repeatedly parsing the same XML file again and again, because when I dump jstack, I've seen a lot of different XML parsers there. This MIGHT be triggered by a @Parameterized junit test with 50,000 cases. In any case, this has made Jenkins totally unusable. It also dies when we have a single JUnit case with a 1Gb output XML, but we have worked around that. But we cannot reduce the size of our test suite just to keep Jenkins happy. Reported critical as this has stopped us from using Jenkins. Tempted to report blocker. Here is some stack. ``` at com.thoughtworks.xstream.mapper.AnnotationMapper.processAnnotations(AnnotationMapper.java:180) at com.thoughtworks.xstream.mapper.AnnotationMapper.defaultImplementationOf(AnnotationMapper.java:141) at hudson.util.xstream.MapperDelegate.defaultImplementationOf(MapperDelegate.java:59) at com.thoughtworks.xstream.mapper.MapperWrapper.defaultImplementationOf(MapperWrapper.java:46) at hudson.util.RobustReflectionConverter.determineType(RobustReflectionConverter.java:475) at hudson.util.RobustReflectionConverter.doUnmarshal(RobustReflectionConverter.java:327) at hudson.util.RobustReflectionConverter.unmarshal(RobustReflectionConverter.java:270) at com.thoughtworks.xstream.core.TreeUnmarshaller.convert(TreeUnmarshaller.java:72) at com.thoughtworks.xstream.core.AbstractReferenceUnmarshaller.convert(AbstractReferenceUnmarshaller.java:65) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:66) at com.thoughtworks.xstream.core.TreeUnmarshaller.convertAnother(TreeUnmarshaller.java:50) at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.readItem(AbstractCollectionConverter.java:71) at hudson.util.RobustCollectionConverter.populateCollection(RobustCollectionConverter.java:85) at com.thoughtworks.xstream.converters.collections.CollectionConverter.unmarshal(CollectionConverter.java:80) at hudson.util.RobustCollectionConverter.unmarshal(RobustCollectionConverter.java:76) at
[JIRA] (JENKINS-56243) Jenkins GUI is slow -removing cookie fixes it (temporarily)
Title: Message Title Shevek . commented on JENKINS-56243 Re: Jenkins GUI is slow -removing cookie fixes it (temporarily) Tempted to say this is a major or blocker as it kills our usage of Jenkins on the first non-login request. We do NOT get an hour of usability, we get NO usability on 2.150.3 Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56243) Jenkins GUI is slow -removing cookie fixes it (temporarily)
Title: Message Title Shevek . commented on JENKINS-56243 Re: Jenkins GUI is slow -removing cookie fixes it (temporarily) Downgrade to 2.150.1 appears to solve the issue. Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] (JENKINS-56243) Jenkins GUI is slow -removing cookie fixes it (temporarily)
Title: Message Title Shevek . commented on JENKINS-56243 Re: Jenkins GUI is slow -removing cookie fixes it (temporarily) This appears to be affecting us after the update to 2.150.3 and has made jenkins unusable Add Comment This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d) -- You received this message because you are subscribed to the Google Groups "Jenkins Issues" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [findbugs-plugin] (JENKINS-21723) Findbugs plugin uses absolute URL for link to report
Shevek . commented on JENKINS-21723 Findbugs plugin uses absolute URL for link to report Yes, it is. Everything needs to be relative as findbugs has no idea which proxies I'm accessing it through or what its authoritative name is from the perspective of the client. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [findbugs-plugin] (JENKINS-21723) Findbugs plugin uses absolute URL for link to report
Shevek . commented on JENKINS-21723 Findbugs plugin uses absolute URL for link to report Yes, ssh tunnelling via localhost is one of our primary access methods too. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [findbugs] (JENKINS-21723) Findbugs plugin uses absolute URL for link to report
Shevek . created JENKINS-21723 Findbugs plugin uses absolute URL for link to report Issue Type: Bug Affects Versions: current Assignee: Ulli Hafner Components: findbugs Created: 07/Feb/14 9:41 PM Description: Environment: The jenkins findbugs plugin draws a graph with red and yellow on it for high and low priority issues. Clicking on this report takes me to the findbugs report. This link seems to use an absolute, not a relative URI. Bug: If the jenkins server is multihomed, or accessed over a socks proxy, or by any other means other than simple network access, the link does not work because the "one and only" server name is not resolvable from that client. Editing the browser URL appropriately to point to the client-accessible name of the jenkins server provides access to the report. Navigating within the report also works just fine. Solution: Most other links in jenkins use relative links, and so work fine. Please can this one use a relative link too. Project: Jenkins Priority: Major Reporter: Shevek . This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
