[JIRA] (JENKINS-13928) bad version number at offiset=6
[ https://issues.jenkins-ci.org/browse/JENKINS-13928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christian Wolfgang reassigned JENKINS-13928: Assignee: Christian Wolfgang bad version number at offiset=6 --- Key: JENKINS-13928 URL: https://issues.jenkins-ci.org/browse/JENKINS-13928 Project: Jenkins Issue Type: Bug Components: clearcase-ucm Affects Versions: current Environment: windows xp , tomcat 6.0.35, jenkins 1.465, clearcase-ucm-plugin 1.0.7 Reporter: Carl Chen Assignee: Christian Wolfgang Labels: plugin jenkins runs well, but after install this plugin, it reports bad version number error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13928) bad version number at offiset=6
[ https://issues.jenkins-ci.org/browse/JENKINS-13928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163247#comment-163247 ] Christian Wolfgang commented on JENKINS-13928: -- Is this the version number reported in the installed plugins tab or in the console output? I am well aware of the wrong version number in the console output and it will be fixed in the next version. bad version number at offiset=6 --- Key: JENKINS-13928 URL: https://issues.jenkins-ci.org/browse/JENKINS-13928 Project: Jenkins Issue Type: Bug Components: clearcase-ucm Affects Versions: current Environment: windows xp , tomcat 6.0.35, jenkins 1.465, clearcase-ucm-plugin 1.0.7 Reporter: Carl Chen Assignee: Christian Wolfgang Labels: plugin jenkins runs well, but after install this plugin, it reports bad version number error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11746) OpenID plugin gives NPE in OpenId Plugin at OpenIdSsoSecurityRealm.doFinishLogin(OpenIdSsoSecurityRealm.java:159)
[ https://issues.jenkins-ci.org/browse/JENKINS-11746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163248#comment-163248 ] Urban Novak commented on JENKINS-11746: --- I'm getting similar error with Jenkins 1.465 and openid plugin 1.5-SNAPSHOT (private-05/22/2012 15:53). Problem occurs, when I access jenkins from different url than the one specified in configuration. Let's say, if configured jenkins url is http://jenkins:8080 , then openid SSO works only when I use that url. If I use http://jenkins.mydomain.cz:8080 , openid sso fails with following exception. java.lang.NullPointerException at hudson.plugins.openid.OpenIdSsoSecurityRealm.doFinishLogin(OpenIdSsoSecurityRealm.java:188) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.kohsuke.stapler.Function$InstanceFunction.invoke(Function.java:288) at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:151) at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:90) at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:111) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.MetaClass$4.doDispatch(MetaClass.java:203) at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:53) at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:574) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:659) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:488) at org.kohsuke.stapler.Stapler.service(Stapler.java:162) at javax.servlet.http.HttpServlet.service(HttpServlet.java:45) at winstone.ServletConfiguration.execute(ServletConfiguration.java:248) at winstone.RequestDispatcher.forward(RequestDispatcher.java:333) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:376) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:47) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84) at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:166) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:142) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:173) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at jenkins.security.ApiTokenFilter.doFilter(ApiTokenFilter.java:63) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249) at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:66) at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87) at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76) at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:164) at winstone.FilterConfiguration.execute(FilterConfiguration.java:194) at winstone.RequestDispatcher.doFilter(RequestDispatcher.java:366) at
[JIRA] (JENKINS-9913) Concurrent builds getting batched/nodes not getting released when jobs are completed
[ https://issues.jenkins-ci.org/browse/JENKINS-9913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163249#comment-163249 ] Sergey Smirnov commented on JENKINS-9913: - Any progress? Latest Jenkins has this bug. Concurrent builds getting batched/nodes not getting released when jobs are completed Key: JENKINS-9913 URL: https://issues.jenkins-ci.org/browse/JENKINS-9913 Project: Jenkins Issue Type: Bug Components: concurrent-build Affects Versions: current Environment: RedHat Enterprise Linux 4.8, Jenkins 1.414 Reporter: Philip Metting van Rijn Assignee: Kohsuke Kawaguchi We're experiencing an issue with concurrent builds where Jenkins appears to be associating separate builds (run on different machines) such that they won't be marked as completed until all jobs are completed. For example, if we kick off 5 concurrent builds on 5 different nodes, builds 1-4 won't be marked as completed if build #5 is still running, even though builds 1-4 are finished. I've seen a report of someone experiencing this issue elsewhere: http://groups.google.com/group/jenkinsci-users/browse_thread/thread/e477e25910266d2a?fwc=1 but a solution wasn't posted. We do not have the batch plugin or the locks and latches plugin installed. We've disabled all post-build processing and switched between different containers (Glassfish/Tomcat), but the problem persists. I couldn't find an issue logged for this other than the aforementioned posting. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13264) fail checkout 2 modules with different path
[ https://issues.jenkins-ci.org/browse/JENKINS-13264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163250#comment-163250 ] Valentin Batz commented on JENKINS-13264: -- Michael: I think the backslash trick works on windows client-side only, independend from the cvs-server platform. I haven't tried cvs on linux client yet. I don't recommend to change the CVS command to contain backslashes. I think you should ommit the -d option when the 'CVS Module' contains slashes. The chekckout-as feature does not work with partial checkouts. I'd prefer a working 'partial checkout' feature over the 'checkout-as' feature, since it worked out of the box with versions 2.0 of the CVS Plugin. fail checkout 2 modules with different path --- Key: JENKINS-13264 URL: https://issues.jenkins-ci.org/browse/JENKINS-13264 Project: Jenkins Issue Type: Bug Components: cvs Environment: linux Reporter: Eric Co Assignee: Michael Clarke Fix For: current I create two cvs modules with the path lib/flac-1.2.1 drv/linux/fuse when it check out, got the error: cvs checkout -P -D 29 Mar 2012 11:40:15 +0800 -d lib/flac-1.2.1 lib/flac-1.2.1 cvs [checkout aborted]: could not change directory to requested checkout directory `lib': No such file or directory -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13264) fail checkout 2 modules with different path
[ https://issues.jenkins-ci.org/browse/JENKINS-13264?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163251#comment-163251 ] Valentin Batz commented on JENKINS-13264: -- I've just tried the -d argument on linux client with backslashes, it's not what you want. It creates the directory with the backslash in it. fail checkout 2 modules with different path --- Key: JENKINS-13264 URL: https://issues.jenkins-ci.org/browse/JENKINS-13264 Project: Jenkins Issue Type: Bug Components: cvs Environment: linux Reporter: Eric Co Assignee: Michael Clarke Fix For: current I create two cvs modules with the path lib/flac-1.2.1 drv/linux/fuse when it check out, got the error: cvs checkout -P -D 29 Mar 2012 11:40:15 +0800 -d lib/flac-1.2.1 lib/flac-1.2.1 cvs [checkout aborted]: could not change directory to requested checkout directory `lib': No such file or directory -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10856) Incorrect Cyrillic symbols in Console output
[ https://issues.jenkins-ci.org/browse/JENKINS-10856?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Sviridov updated JENKINS-10856: -- Attachment: msbuild-plugin-1.12.1.zip merge changes with 1.12.1 Incorrect Cyrillic symbols in Console output Key: JENKINS-10856 URL: https://issues.jenkins-ci.org/browse/JENKINS-10856 Project: Jenkins Issue Type: Bug Components: msbuild Affects Versions: current Environment: Windows 7 Rus Reporter: Dmitry Sviridov Assignee: Gregory Boissinot Priority: Minor Attachments: msbuild-plugin-1.11.1.zip, msbuild-plugin-1.12.1.zip, msbuild-plugin-1.8.1.1.Zip, msbuild.hpi, screen.zip Incorrect Cyrillic symbols in Console output. Can be solved by change MsBuildBuilder class Line 122 from: if (!launcher.isUnix()) { args.prepend(cmd.exe, /C); args.add(, exit, %%ERRORLEVEL%%); } To: if (!launcher.isUnix()) { String winCodepage = 1251; args.prepend(cmd.exe, /C, chcp, winCodepage, , NUL, ); args.add(, exit, %%ERRORLEVEL%%); } But winCodepage nead add to configure. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13829) Race condition in Queue.pop()
[ https://issues.jenkins-ci.org/browse/JENKINS-13829?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163254#comment-163254 ] SCM/JIRA link daemon commented on JENKINS-13829: Code changed in jenkins User: Brad Larson Path: gerrithudsontrigger/src/main/java/com/sonyericsson/hudson/plugins/gerrit/trigger/hudsontrigger/GerritTrigger.java http://jenkins-ci.org/commit/gerrit-trigger-plugin/ef82c75b5ce7433936a57108e1a3f6638093768a Log: Fix behavior of canceling old patch sets There were several problems with canceling jobs created by old patch sets when new patch sets are uploaded. We were removing old jobs when scheduled() was called, but then removed() was also called, which would cancel the newly-added build we care about. Instead, we now store the PatchsetCreated event to track the jobs, and cancel all jobs for a particular Change # when a new patch set is uploaded but only remove the exact job when remove() is called. There was also a problem in calling Future.cancel(), as documented in https://issues.jenkins-ci.org/browse/JENKINS-13829. This was worked around by storing the parameters used to create each build and canceling jobs with the same parameters. This is more in-line with how jobs are canceled from the Web UI. Race condition in Queue.pop() - Key: JENKINS-13829 URL: https://issues.jenkins-ci.org/browse/JENKINS-13829 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Reporter: bklarson I have ran into a race condition with multiple Executors calling Queue.pop() at the same time. The task's FutureImpl is being told executor A will run the task, but it ends up running on executor B. Later when I call FutureImpl.cancel(), the wrong thread is interrupted. If another task is running on executor A, that task is canceled instead. I ran into this while trying to fix the GerritTriggerPlugin. The plugin schedules jobs when code is uploaded to Gerrit. If that change in Gerrit gets amended, the plugin can cancel the current job before scheduling the new job. This makes sense, because we no longer care about the results of the build since that code will no be used. Because of this behavior, one Executor (B) is running the item and gets canceled when another Executor (A) starts loading the new item. Executor A calls Queue.pop(), and in the maintain() call it sets the new item's FutureImpl's executor to itself (A) and signals the JobOffer's event. In the mean time, Executor B also calls pop() since its last job has just been canceled. It ends up getting the JobOffer which A just signaled. Now the task is running on Executor B but thinks it is running on Executor A. Is there a work-around to cancel a FutureImpl in this case? Maybe scan through all Executors to find the one running the task we are interested in? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13933) Arrows in dashboard column headings are inconsistent
Paul Croome created JENKINS-13933: - Summary: Arrows in dashboard column headings are inconsistent Key: JENKINS-13933 URL: https://issues.jenkins-ci.org/browse/JENKINS-13933 Project: Jenkins Issue Type: Improvement Components: dashboard-view Affects Versions: current Environment: Sun/Solaris 9; Java 1.6.0_10; Jenkins ver. 1.466 Reporter: Paul Croome Assignee: Peter Hayes Priority: Trivial The arrows that indicate the sorting direction (ascending/descending) in the dashboard column headings seem to be inconsistent. In the 'Name' column, a down-arrow indicates ascending. In the 'Last Success' column, a down-arrow indicates descending. In the 'Last Failure' column, a down-arrow indicates descending. In the 'Last Duration' column, a down-arrow indicates ascending. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13934) Make it possible to delete all except latest 'n' archived artifacts
Paul Croome created JENKINS-13934: - Summary: Make it possible to delete all except latest 'n' archived artifacts Key: JENKINS-13934 URL: https://issues.jenkins-ci.org/browse/JENKINS-13934 Project: Jenkins Issue Type: Improvement Components: postbuild-task Affects Versions: current Environment: Sun/Solaris 9 ; Java 1.6.0_10; Jenkins ver. 1.466 Reporter: Paul Croome Priority: Minor In the job configuration page, under Post-build Actions Archive the Artifacts Advanced it's possible to select the checkbox Discard all but the last successful/stable artifact to save disk space. It would be useful if I could choose Discard all but the last 'n' successful/stable artifacts to save disk space. (By comparison: The option Discard Old Builds allows me to specify Max # of builds to keep. A similar feature for archived artifacts would be nice.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13825) Sounds plugin configuration System command is empty
[ https://issues.jenkins-ci.org/browse/JENKINS-13825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163256#comment-163256 ] Bernard McKeever commented on JENKINS-13825: I'm seeing the same behavior. Extremely annoying. Sounds plugin configuration System command is empty - Key: JENKINS-13825 URL: https://issues.jenkins-ci.org/browse/JENKINS-13825 Project: Jenkins Issue Type: Bug Components: sounds Environment: Jenkins 1.463, Jenkins Sounds plugin 0.4 Reporter: Hua Zhang Jenkins 1.463, Jenkins Sounds Plugin 0.4. On the global configuration page, the value of input field System command is not saved. Set the value directly in {{net.hurstfrost.hudson.sounds.HudsonSoundsNotifier.xml}} and load config from disk seems to temporarily solve the problem. But eventually it becomes emtpy again if the configuration is changed and saved. Visiting the configure page causes the following stacktrace in log. {code} 18.05.2012 15:41:25 hudson.ExpressionFactory2$JexlExpression evaluate WARNUNG: Caught exception evaluating: descriptor.getPropertyType(instance,field).itemTypeDescriptorOrDie. Reason: java.lang.reflect.InvocationTargetException java.lang.reflect.InvocationTargetException at sun.reflect.GeneratedMethodAccessor502.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.commons.jexl.util.PropertyExecutor.execute(PropertyExecutor.java:125) at org.apache.commons.jexl.util.introspection.UberspectImpl$VelGetterImpl.invoke(UberspectImpl.java:314) at org.apache.commons.jexl.parser.ASTArrayAccess.evaluateExpr(ASTArrayAccess.java:185) at org.apache.commons.jexl.parser.ASTIdentifier.execute(ASTIdentifier.java:75) at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83) at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57) at org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51) at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) at hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:72) at org.apache.commons.jelly.tags.core.CoreTagLibrary$3.run(CoreTagLibrary.java:134) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.tags.core.WhenTag.doTag(WhenTag.java:46) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.tags.core.ChooseTag.doTag(ChooseTag.java:38) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119) at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98) at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.ReallyStaticTagLibrary$1.run(ReallyStaticTagLibrary.java:99) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.CallTagLibScript.run(CallTagLibScript.java:119) at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98) at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.kohsuke.stapler.jelly.CallTagLibScript$1.run(CallTagLibScript.java:98) at org.apache.commons.jelly.tags.define.InvokeBodyTag.doTag(InvokeBodyTag.java:91) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:270) at
[JIRA] (JENKINS-5053) SocketTimeoutException after build start
[ https://issues.jenkins-ci.org/browse/JENKINS-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Warren V updated JENKINS-5053: -- Attachment: jenkins.pcap Capture of bad CIFS traffic from Jenkins SocketTimeoutException after build start Key: JENKINS-5053 URL: https://issues.jenkins-ci.org/browse/JENKINS-5053 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: All Reporter: dtriphaus Attachments: jenkins.pcap Shortly after starting a build from hudson, SOMETIMES the following error occurs: Started by timer [workspace] $ cvs -q update ... Parsing POMs [workspace] $ /opt/mvn/jvm/java-1.5.0-sun/bin/java -cp ... ERROR: Aborted Maven execution for InterruptedIOException java.net.SocketTimeoutException: Accept timed out at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384) at java.net.ServerSocket.implAccept(ServerSocket.java:450) at java.net.ServerSocket.accept(ServerSocket.java:421) at hudson.maven.MavenProcessFactory$SocketHandler$AcceptorImpl.accept(MavenProcessFactory.java:167) at hudson.maven.MavenProcessFactory.newProcess(MavenProcessFactory.java:202) at hudson.maven.ProcessCache.get(ProcessCache.java:227) at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:455) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:417) at hudson.model.Run.run(Run.java:1176) at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:304) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:123) Finished: ABORTED -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13935) Debian Squeeze Installation
Clement Gautier created JENKINS-13935: - Summary: Debian Squeeze Installation Key: JENKINS-13935 URL: https://issues.jenkins-ci.org/browse/JENKINS-13935 Project: Jenkins Issue Type: Bug Components: core Environment: java version 1.6.0_18 OpenJDK Runtime Environment (IcedTea6 1.8.13) (6b18-1.8.13-0+squeeze1) OpenJDK 64-Bit Server VM (build 14.0-b16, mixed mode) Debian Squeeze 6.0.5 (and 6.0.4) Reporter: Clement Gautier Attachments: hs_err_pid23165.log Hi, I am having some trouble installing Jenkins ci on a Debian squeeze. I did : {code} apt-get install openjdk-6-jre openjdk-6-jdk jenkins {code} During the Jenkins installation I got this errors : {code} root@hudson:~# tail -f /var/log/jenkins/jenkins.log Running from: /usr/share/jenkins/jenkins.war May 29, 2012 10:38:39 AM winstone.Logger logInternal INFO: Beginning extraction from war file Exception in thread Reference Handler java.lang.IllegalMonitorStateException at java.lang.Object.notifyAll(Native Method) at java.lang.ref.ReferenceQueue.enqueue(ReferenceQueue.java:68) at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:146) Jenkins home directory: /var/lib/jenkins found at: EnvVars.masterEnvVars.get(JENKINS_HOME) {code} After this error, the folder /var/lib/jenkins is created but empty, the user jenkins is still runing tasks : {code} root@hudson:~# ps -u jenkins PID TTY TIME CMD 10467 ?00:00:00 daemon 10469 ?00:00:04 java {code} And, of course, I get nothing in ip:8080 on my browser I already submitted this bug to the java team on their bug tracker here : http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=987 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13928) bad version number at offiset=6
[ https://issues.jenkins-ci.org/browse/JENKINS-13928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163258#comment-163258 ] Carl Chen commented on JENKINS-13928: - i'm not quite sure now. i just download the latest plugin and install and then see this error on the console of tomcat bad version number at offiset=6 --- Key: JENKINS-13928 URL: https://issues.jenkins-ci.org/browse/JENKINS-13928 Project: Jenkins Issue Type: Bug Components: clearcase-ucm Affects Versions: current Environment: windows xp , tomcat 6.0.35, jenkins 1.465, clearcase-ucm-plugin 1.0.7 Reporter: Carl Chen Assignee: Christian Wolfgang Labels: plugin jenkins runs well, but after install this plugin, it reports bad version number error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
REMOVE ME
Martin Schoepf - Software Testing TTTech Computertechnik AG - Ensuring Reliable Networks Commercial Reg. No.: 165 664z, Commercial Court Vienna Schoenbrunner Strasse 7, A-1040 Vienna, Austria Phone: +43 1 585 34 34-46, Fax: +43 1 585 34 34-90 martin.scho...@tttech.com, http://www.tttech.com ___ From: lst...@gmail.com (JIRA) nore...@jenkins-ci.org To: jenkinsci-issues@googlegroups.com Date: 05.09.2012 05:08 Subject: [JIRA] (JENKINS-9679) NoClassDefFoundError on Base64 when launching an headless slave with -jnlpCredential option Sent by: jenkinsci-issues@googlegroups.com [ https://issues.jenkins-ci.org/browse/JENKINS-9679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=162591#comment-162591 ] Liam Staskawicz commented on JENKINS-9679: -- Would love to see this addressed or elevated in priority - this is a critical component of putting together a master/slave cluster, and has been known for just about a year now. I say this without being able to fix it myself of course :) but this would be a great help to people setting up multi configuration systems. NoClassDefFoundError on Base64 when launching an headless slave with -jnlpCredential option --- Key: JENKINS-9679 URL: https://issues.jenkins-ci.org/browse/JENKINS-9679 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Jenkins 1.411 / MacOS X / JDK 1.6.0_24 Jenkins 1.412 / Master: Ubuntu 10.04, / Slave: Windows Server 2008 x64, JDK 1.6.0_20 Jenkins 1.424.2 / Master: CentOS 5.5, / Slave: Windows Server 2008 R2 x64, JDK 1.6.0_21 Reporter: Olivier Mansion When launching a headless slave, a NoClassDefFoundError on org/apache/commons/codec/binary/Base64 is raised when specifying the -jnlpCredential option: $ java -jar slave.jar -jnlpUrl url -jnlpCredentials user:password Exception in thread main java.lang.NoClassDefFoundError: org/apache/commons/codec/binary/Base64 at hudson.remoting.Launcher.parseJnlpArguments(Launcher.java:221) at hudson.remoting.Launcher.run(Launcher.java:192) at hudson.remoting.Launcher.main(Launcher.java:168) Caused by: java.lang.ClassNotFoundException: org.apache.commons.codec.binary.Base64 at java.net.URLClassLoader$1.run(URLClassLoader.java:202) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:190) at java.lang.ClassLoader.loadClass(ClassLoader.java:307) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301) at java.lang.ClassLoader.loadClass(ClassLoader.java:248) ... 3 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira CONFIDENTIALITY: The contents of this e-mail are confidential and intended only for the above addressee(s). If you are not the intended recipient, or the person responsible for delivering it to the intended recipient, copying or delivering it to anyone else or using it in any unauthorized manner is prohibited and may be unlawful. If you receive this e-mail by mistake, please notify the sender and the systems administrator at straym...@tttech.com immediately.
[JIRA] (JENKINS-9833) Enhanced description of Artifact syntax in web server interface
[ https://issues.jenkins-ci.org/browse/JENKINS-9833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Laws resolved JENKINS-9833. - Fix Version/s: current Resolution: Duplicate Enhanced description of Artifact syntax in web server interface --- Key: JENKINS-9833 URL: https://issues.jenkins-ci.org/browse/JENKINS-9833 Project: Jenkins Issue Type: Improvement Environment: Any Reporter: Aaron Laws Priority: Trivial Fix For: current The documentation on the web service when configuring a project, under Post-build Actions Archive the artifacts could use one point of clarity, namely, the noted ability to specify multiple artifact locations using the , operator. I had to search the web to find this functionality, but I think it would be very appropriate in the web interface itself. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9833) Enhanced description of Artifact syntax in web server interface
[ https://issues.jenkins-ci.org/browse/JENKINS-9833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Laws closed JENKINS-9833. --- Enhanced description of Artifact syntax in web server interface --- Key: JENKINS-9833 URL: https://issues.jenkins-ci.org/browse/JENKINS-9833 Project: Jenkins Issue Type: Improvement Environment: Any Reporter: Aaron Laws Priority: Trivial Fix For: current The documentation on the web service when configuring a project, under Post-build Actions Archive the artifacts could use one point of clarity, namely, the noted ability to specify multiple artifact locations using the , operator. I had to search the web to find this functionality, but I think it would be very appropriate in the web interface itself. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13863) MSBuild is unable to build projects in a different directory
[ https://issues.jenkins-ci.org/browse/JENKINS-13863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163259#comment-163259 ] Aaron Laws commented on JENKINS-13863: -- I'm not sure what the problem is. I can reproduce it reliably, though. If the solution file is in a child directory of the PWD, I cannot build the project directly using the msbuild plugin, but must add a build step before msbuild to change the PWD (something like {{cd proj}}). Perhaps some sample output is helpful. MSBuild is unable to build projects in a different directory Key: JENKINS-13863 URL: https://issues.jenkins-ci.org/browse/JENKINS-13863 Project: Jenkins Issue Type: Bug Components: msbuild Affects Versions: current Environment: MS Windows Server 2008 Reporter: Aaron Laws Assignee: kdsweeney Priority: Minor Labels: path, plugin I use SVN to checkout a project to {{.\proj\}} and a dependency to {{.\dep\}}. The {{.sln}} file is at {{.\proj\proj.sln}}. I us the MsBuild plugin with the setting MsBuild Build File = {{proj\proj.sln}} (or a number of variants such as {{.\proj\proj.sln}}). Msbuild fails with {{MSB1009: Project file does not exist.}} However, running a similar command manually succeeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11577) Matrix axis are not recognixed as parameter
[ https://issues.jenkins-ci.org/browse/JENKINS-11577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163260#comment-163260 ] Vlad Aginsky commented on JENKINS-11577: Hi, Is there any progress on this? Matrix axis are not recognixed as parameter --- Key: JENKINS-11577 URL: https://issues.jenkins-ci.org/browse/JENKINS-11577 Project: Jenkins Issue Type: Bug Components: parameterized-trigger Reporter: Jens Baitinger Assignee: huybrechts Attachments: jobs.zip, nonparam.png We want to want to create a matrix job which triggers the current another job with the current matrix parameters. Concrete example: Our setup creation consists of two steps. The first job (prepare-setup) is to collect all the files and potentially encrypt them, the second step (setup) is to create a setup.exe. prepare-setup is a matix build with the ecryption option as its values (encrypted, unencrypted). The second job should be triggered with the encryption option as its parameter, so that we have an encryted setup (for the customers) and an unencrypted (for internal tests and debugging) Currenty the setup job is triggered twice, both with the value $encryption for the encryption parameter. (see screenshot) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13863) MSBuild is unable to build projects in a different directory
[ https://issues.jenkins-ci.org/browse/JENKINS-13863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aaron Laws updated JENKINS-13863: - Attachment: goodconfig.PNG badconfig.PNG badbuild.txt goodbuild.txt Attached are a screen shot of a configuration that works and one that ought to work but doesn't along with both outputs in text format. MSBuild is unable to build projects in a different directory Key: JENKINS-13863 URL: https://issues.jenkins-ci.org/browse/JENKINS-13863 Project: Jenkins Issue Type: Bug Components: msbuild Affects Versions: current Environment: MS Windows Server 2008 Reporter: Aaron Laws Assignee: kdsweeney Priority: Minor Labels: path, plugin Attachments: badbuild.txt, badconfig.PNG, goodbuild.txt, goodconfig.PNG I use SVN to checkout a project to {{.\proj\}} and a dependency to {{.\dep\}}. The {{.sln}} file is at {{.\proj\proj.sln}}. I us the MsBuild plugin with the setting MsBuild Build File = {{proj\proj.sln}} (or a number of variants such as {{.\proj\proj.sln}}). Msbuild fails with {{MSB1009: Project file does not exist.}} However, running a similar command manually succeeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12598) In 2.0 update you need to specify branch for every module
[ https://issues.jenkins-ci.org/browse/JENKINS-12598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fred G reopened JENKINS-12598: -- Sorry for reopening this issue. I tested version 2.4-SNAPSHOT. During the upgrade from version 2.3 all module configurations got lost. So I had to cumbersomely add modules and reinsert each module name. Before 2.4 is publicly released we should try to implement an automated migration mechanism, otherwise we risk another user/dev list bashing. I still think the user should have the choice between an individual and list-oriented module configuration. In 2.0 update you need to specify branch for every module - Key: JENKINS-12598 URL: https://issues.jenkins-ci.org/browse/JENKINS-12598 Project: Jenkins Issue Type: Improvement Components: cvs Reporter: Ulli Hafner Assignee: Michael Clarke Priority: Critical Attachments: Jenkins_CvsPluginModules.png, repositoryLocationProposal.png After an upgrade to the new 2.0 version of the cvs plug-in we now need to specify the Module location (trunk, branch) for each module. This is quite cumbersome if you have a lot of modules. In the 1.x plug-in releases you are able to select a given branch for all modules in one text field. While I think the new feature has a lot of use cases (i.e., having trunk and branches mixed), the usability could be improved here. My requirement is to select/change the branch (or trunk) for all modules in a simple way. A non-Ajax suggestion would be to have a default entry in the Selection, i.e. Trunk, Branch, Tag, Default. And you can define the default behavior at the top of the cvs configuration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13928) bad version number at offiset=6
[ https://issues.jenkins-ci.org/browse/JENKINS-13928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163263#comment-163263 ] Christian Wolfgang commented on JENKINS-13928: -- Could you please provide the console output? bad version number at offiset=6 --- Key: JENKINS-13928 URL: https://issues.jenkins-ci.org/browse/JENKINS-13928 Project: Jenkins Issue Type: Bug Components: clearcase-ucm Affects Versions: current Environment: windows xp , tomcat 6.0.35, jenkins 1.465, clearcase-ucm-plugin 1.0.7 Reporter: Carl Chen Assignee: Christian Wolfgang Labels: plugin jenkins runs well, but after install this plugin, it reports bad version number error. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13936) Fitnesse results parsing uses too much heap
recampbell created JENKINS-13936: Summary: Fitnesse results parsing uses too much heap Key: JENKINS-13936 URL: https://issues.jenkins-ci.org/browse/JENKINS-13936 Project: Jenkins Issue Type: Bug Components: fitnesse Reporter: recampbell We are seeing OOME's in Jenkins when parsing large Fitnesse results files (35mb). For example: {quote} Reading results as US-ASCII from /.../fitnesse-result.xml Parsing results... java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2882) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:515) at java.lang.StringBuffer.append(StringBuffer.java:306) at com.sun.org.apache.xalan.internal.xsltc.runtime.StringValueHandler.characters(StringValueHandler.java:49) at com.sun.org.apache.xml.internal.utils.FastStringBuffer.sendSAXcharacters(FastStringBuffer.java:998) at com.sun.org.apache.xml.internal.dtm.ref.sax2dtm.SAX2DTM2.dispatchCharactersEvents(SAX2DTM2.java:3068) at com.sun.org.apache.xalan.internal.xsltc.dom.SAXImpl.characters(SAXImpl.java:1562) at com.sun.org.apache.xalan.internal.xsltc.dom.DOMAdapter.characters(DOMAdapter.java:330) at GregorSamsa.template$dot$2() at GregorSamsa.applyTemplates() at GregorSamsa.template$dot$0() at GregorSamsa.applyTemplates() at GregorSamsa.applyTemplates() at GregorSamsa.transform() at com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet.transform(AbstractTranslet.java:603) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:709) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:313) at hudson.plugins.fitnesse.NativePageCountsParser.transformRawResults(NativePageCountsParser.java:25) at hudson.plugins.fitnesse.NativePageCountsParser.parse(NativePageCountsParser.java:17) at hudson.plugins.fitnesse.FitnesseResultsRecorder.getResults(FitnesseResultsRecorder.java:131) at hudson.plugins.fitnesse.FitnesseResultsRecorder.getResults(FitnesseResultsRecorder.java:109) at hudson.plugins.fitnesse.FitnesseResultsRecorder.perform(FitnesseResultsRecorder.java:73) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:705) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:680) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:658) at hudson.model.Build$RunnerImpl.post2(Build.java:161) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:627) at hudson.model.Run.run(Run.java:1400) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) Build step 'Publish Fitnesse results report' changed build result to FAILURE Build step 'Publish Fitnesse results report' marked build as failure {quote} Perhaps it would be more efficient to use a streaming parser like SAX? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13936) Fitnesse results parsing uses too much heap
[ https://issues.jenkins-ci.org/browse/JENKINS-13936?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] recampbell updated JENKINS-13936: - Description: We are seeing OOME's in Jenkins when parsing large Fitnesse results files (35mb). For example: {quote} Reading results as US-ASCII from /.../fitnesse-result.xml Parsing results... java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2882) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:515) at java.lang.StringBuffer.append(StringBuffer.java:306) at com.sun.org.apache.xalan.internal.xsltc.runtime.StringValueHandler.characters(StringValueHandler.java:49) at com.sun.org.apache.xml.internal.utils.FastStringBuffer.sendSAXcharacters(FastStringBuffer.java:998) at com.sun.org.apache.xml.internal.dtm.ref.sax2dtm.SAX2DTM2.dispatchCharactersEvents(SAX2DTM2.java:3068) at com.sun.org.apache.xalan.internal.xsltc.dom.SAXImpl.characters(SAXImpl.java:1562) at com.sun.org.apache.xalan.internal.xsltc.dom.DOMAdapter.characters(DOMAdapter.java:330) at GregorSamsa.template$dot$2() at GregorSamsa.applyTemplates() at GregorSamsa.template$dot$0() at GregorSamsa.applyTemplates() at GregorSamsa.applyTemplates() at GregorSamsa.transform() at com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet.transform(AbstractTranslet.java:603) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:709) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:313) at hudson.plugins.fitnesse.NativePageCountsParser.transformRawResults(NativePageCountsParser.java:25) at hudson.plugins.fitnesse.NativePageCountsParser.parse(NativePageCountsParser.java:17) at hudson.plugins.fitnesse.FitnesseResultsRecorder.getResults(FitnesseResultsRecorder.java:131) at hudson.plugins.fitnesse.FitnesseResultsRecorder.getResults(FitnesseResultsRecorder.java:109) at hudson.plugins.fitnesse.FitnesseResultsRecorder.perform(FitnesseResultsRecorder.java:73) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:705) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:680) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:658) at hudson.model.Build$RunnerImpl.post2(Build.java:161) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:627) at hudson.model.Run.run(Run.java:1400) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) Build step 'Publish Fitnesse results report' changed build result to FAILURE Build step 'Publish Fitnesse results report' marked build as failure {quote} I'm fairly certain this OOME is due to memory usage by this parsing since we don't see OOME at any other time, and there is plenty of memory usually available according to our monitoring. was: We are seeing OOME's in Jenkins when parsing large Fitnesse results files (35mb). For example: {quote} Reading results as US-ASCII from /.../fitnesse-result.xml Parsing results... java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2882) at java.lang.AbstractStringBuilder.expandCapacity(AbstractStringBuilder.java:100) at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:515) at java.lang.StringBuffer.append(StringBuffer.java:306) at com.sun.org.apache.xalan.internal.xsltc.runtime.StringValueHandler.characters(StringValueHandler.java:49) at com.sun.org.apache.xml.internal.utils.FastStringBuffer.sendSAXcharacters(FastStringBuffer.java:998) at com.sun.org.apache.xml.internal.dtm.ref.sax2dtm.SAX2DTM2.dispatchCharactersEvents(SAX2DTM2.java:3068) at com.sun.org.apache.xalan.internal.xsltc.dom.SAXImpl.characters(SAXImpl.java:1562) at com.sun.org.apache.xalan.internal.xsltc.dom.DOMAdapter.characters(DOMAdapter.java:330) at GregorSamsa.template$dot$2() at GregorSamsa.applyTemplates() at GregorSamsa.template$dot$0() at GregorSamsa.applyTemplates() at GregorSamsa.applyTemplates() at GregorSamsa.transform() at com.sun.org.apache.xalan.internal.xsltc.runtime.AbstractTranslet.transform(AbstractTranslet.java:603) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:709) at com.sun.org.apache.xalan.internal.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:313) at hudson.plugins.fitnesse.NativePageCountsParser.transformRawResults(NativePageCountsParser.java:25) at hudson.plugins.fitnesse.NativePageCountsParser.parse(NativePageCountsParser.java:17) at
[JIRA] (JENKINS-12312) JIRA Plugin: Consider JiraIssueParameterValue when collecting issue ids to update
[ https://issues.jenkins-ci.org/browse/JENKINS-12312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Hansche closed JENKINS-12312. - JIRA Plugin: Consider JiraIssueParameterValue when collecting issue ids to update - Key: JENKINS-12312 URL: https://issues.jenkins-ci.org/browse/JENKINS-12312 Project: Jenkins Issue Type: New Feature Components: jira Affects Versions: current Reporter: Joe Hansche Assignee: Joe Hansche Priority: Minor Labels: plugin Currently only issues listed in SCM commit messages will be updated following a build. As of version 1.29, there is a new Parameter definition that allows listing/selecting JIRA issues as a result of a JQL filter. If the build has that parameter set, then the selected issue(s) should also be considered for updating. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13075) Subversion plugin should allow environment variables in the Repository URL
[ https://issues.jenkins-ci.org/browse/JENKINS-13075?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163264#comment-163264 ] Elwood Johnson commented on JENKINS-13075: -- I need this very much and do not consider it trivial. We I need to build for a branch or tag I have to edit all my projects. Subversion plugin should allow environment variables in the Repository URL -- Key: JENKINS-13075 URL: https://issues.jenkins-ci.org/browse/JENKINS-13075 Project: Jenkins Issue Type: Improvement Components: subversion Affects Versions: current Reporter: Leandro Siqueira Priority: Trivial Attachments: svn.JPG I have a parametrized build with a Choice parameter (named Branch) that shows a list of existing branches. When I put this environment variable in the Repository URL Jenkins shows an error message (see attached image), but the build works as expected. It would be nice if we had an option to allow the Repository URL to contain a environment variable, so in this case no error message would appear. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13896) Exception when multiple end markers present on page
[ https://issues.jenkins-ci.org/browse/JENKINS-13896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163265#comment-163265 ] SCM/JIRA link daemon commented on JENKINS-13896: Code changed in jenkins User: Joe Hansche Path: pom.xml src/main/java/com/myyearbook/hudson/plugins/confluence/wiki/editors/BetweenTokensEditor.java http://jenkins-ci.org/commit/confluence-publisher-plugin/c03fa8b25dde388ecc1e4e6bef142c90f23ec9db Log: [Fix JENKINS-13896] End marker must come after start marker. Exception when multiple end markers present on page --- Key: JENKINS-13896 URL: https://issues.jenkins-ci.org/browse/JENKINS-13896 Project: Jenkins Issue Type: Bug Components: confluence-publisher Reporter: Sampo Niskanen Assignee: Joe Hansche When using the Replace content between start/end tokens if the end marker exists in multiple places on the page, the first marker is selected even if it is before the start marker. This results in failure with the following stack trace: [confluence] Performing wiki edits: Replace content between start/end tokens ERROR: Publisher com.myyearbook.hudson.plugins.confluence.ConfluencePublisher aborted due to exception java.lang.StringIndexOutOfBoundsException at java.lang.AbstractStringBuilder.delete(AbstractStringBuilder.java:702) at java.lang.StringBuffer.delete(StringBuffer.java:373) at com.myyearbook.hudson.plugins.confluence.wiki.editors.BetweenTokensEditor.performEdits(BetweenTokensEditor.java:57) at com.myyearbook.hudson.plugins.confluence.wiki.editors.MarkupEditor.performReplacement(MarkupEditor.java:57) at com.myyearbook.hudson.plugins.confluence.ConfluencePublisher.performEdits(ConfluencePublisher.java:394) at com.myyearbook.hudson.plugins.confluence.ConfluencePublisher.performWikiReplacements(ConfluencePublisher.java:353) at com.myyearbook.hudson.plugins.confluence.ConfluencePublisher.perform(ConfluencePublisher.java:327) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:685) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:632) at hudson.model.Run.run(Run.java:1459) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) The fix for this is trivial, just search for the next end token *after* the start token. I.e. change line 45 in BetweenTokensEditor.java from final int end = content.indexOf(endMarkerToken); to final int end = content.indexOf(endMarkerToken, start); Ideally both start and end token is unique on the page, but for example when using the DIV macro to create a page portion to replace the end token is always /ac:rich-text-body/ac:macro. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13896) Exception when multiple end markers present on page
[ https://issues.jenkins-ci.org/browse/JENKINS-13896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Hansche resolved JENKINS-13896. --- Resolution: Fixed Thanks for the report and for tracking down the cause. I've committed a fix, and will be releasing an updated version shortly. You probably won't see it in your update center until tomorrow. Exception when multiple end markers present on page --- Key: JENKINS-13896 URL: https://issues.jenkins-ci.org/browse/JENKINS-13896 Project: Jenkins Issue Type: Bug Components: confluence-publisher Reporter: Sampo Niskanen Assignee: Joe Hansche When using the Replace content between start/end tokens if the end marker exists in multiple places on the page, the first marker is selected even if it is before the start marker. This results in failure with the following stack trace: [confluence] Performing wiki edits: Replace content between start/end tokens ERROR: Publisher com.myyearbook.hudson.plugins.confluence.ConfluencePublisher aborted due to exception java.lang.StringIndexOutOfBoundsException at java.lang.AbstractStringBuilder.delete(AbstractStringBuilder.java:702) at java.lang.StringBuffer.delete(StringBuffer.java:373) at com.myyearbook.hudson.plugins.confluence.wiki.editors.BetweenTokensEditor.performEdits(BetweenTokensEditor.java:57) at com.myyearbook.hudson.plugins.confluence.wiki.editors.MarkupEditor.performReplacement(MarkupEditor.java:57) at com.myyearbook.hudson.plugins.confluence.ConfluencePublisher.performEdits(ConfluencePublisher.java:394) at com.myyearbook.hudson.plugins.confluence.ConfluencePublisher.performWikiReplacements(ConfluencePublisher.java:353) at com.myyearbook.hudson.plugins.confluence.ConfluencePublisher.perform(ConfluencePublisher.java:327) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:685) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:632) at hudson.model.Run.run(Run.java:1459) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) The fix for this is trivial, just search for the next end token *after* the start token. I.e. change line 45 in BetweenTokensEditor.java from final int end = content.indexOf(endMarkerToken); to final int end = content.indexOf(endMarkerToken, start); Ideally both start and end token is unique on the page, but for example when using the DIV macro to create a page portion to replace the end token is always /ac:rich-text-body/ac:macro. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13904) EnvInject Plugin: option to replace invalid characters in env var names with underscores
[ https://issues.jenkins-ci.org/browse/JENKINS-13904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163267#comment-163267 ] Chris Fraser commented on JENKINS-13904: I could write a shell script to convert files so the property.names.with.dots are property_names_with_underscores and then inject them via envinject plugin, but since I'd have to do that again and again for each of my jenkins builds, I felt that it would make better sense to have envinject plugin handle this itself. I agree with you that many languages that are in use in Jenkins accept dots as valid chars in variable names, but when I couldn't get the Git plugin to recognize them (Tag ${app.version}.4 does not exist..., when it should be Tag 31.0 does not exist...), then I thought this was a larger issue than simply dealing with unix shells. Since this feature would be optional, I still think it would be nice to allow envinject plugin to process the env var names before exposing them, if the user so desired. EnvInject Plugin: option to replace invalid characters in env var names with underscores Key: JENKINS-13904 URL: https://issues.jenkins-ci.org/browse/JENKINS-13904 Project: Jenkins Issue Type: New Feature Components: envinject Reporter: Chris Fraser Assignee: Gregory Boissinot Attachments: application.properties, envinject-with-new-option.jpg, injected-environment-variables.jpg I've got a Java properties file (example attached), which I don't have the ability to modify, that I'm sourcing via EnvInject and this file contains keys which are dot delimited (ex: app.version). EnvInject correctly pulls these in as I've verified on the Injected environment variables screen, but they are unresolvable when trying to use them in the job. For instance, when trying to use ${app.version} w/the Git plugin to tag a build, I get: Tag ${app.version}.4 does not exist..., and when I try to use it when executing a shell, I get: ${app.version}: bad substitution. Keys without dots from this same properties file work just fine... unfortunately I need access to the ones w/the dots. After doing a bit of research, I understand why this is happening. 1st of all, you have posted JIRA issues where kohsuke says that env vars w/dots will not be expanded in Jenkins: https://issues.jenkins-ci.org/browse/JENKINS-7180 Then, by doing a quick google search, you'll see that dots in env vars are not supported in most shells and people say to just stay away from them. With that in mind, I think a great feature to add to the EnvInject plugin would be to give users the option to replace the dots (and actually any other which are invalid in env var names) that appear in environment variable names with an underscore. If you look at this issue that was opened against the SharedObjects plugin, you'll see that, ...environment variables from tool names replaces a space, a dash or a dot to by a underscore. https://issues.jenkins-ci.org/browse/JENKINS-13673 Please see attached properties files and screenshots. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13637) Cannot release using M3
[ https://issues.jenkins-ci.org/browse/JENKINS-13637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163268#comment-163268 ] Joe Hansche commented on JENKINS-13637: --- @jglick, is there a workaround to resolve this issue? Or is the only way to fix it to install M2? Cannot release using M3 --- Key: JENKINS-13637 URL: https://issues.jenkins-ci.org/browse/JENKINS-13637 Project: Jenkins Issue Type: Bug Components: plugin Environment: Ubuntu, JDK 6 Reporter: jglick Labels: maven, release-plugin Given the {{mercurial}} plugin with parent {{org.jenkins-ci.plugins:plugin:1.400}}, but also reproducible with {{1.461}}, Maven 3 {{mvn -B release:prepare}} fails with {code} [INFO] Checking dependencies and plugins for snapshots ... [INFO] Transforming 'Jenkins Mercurial plugin'... Downloading: CENTRAL_MIRROR/org/jenkins-ci/tools/maven-hpi-plugin/1.74/maven-hpi-plugin-1.74.pom [WARNING] The POM for org.jenkins-ci.tools:maven-hpi-plugin:jar:1.74 is missing, no dependency information available Downloading: CENTRAL_MIRROR/org/jenkins-ci/tools/maven-hpi-plugin/1.74/maven-hpi-plugin-1.74.jar [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 5.310s [INFO] Finished at: Fri Apr 27 19:30:03 EDT 2012 [INFO] Final Memory: 10M/164M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.2.1:prepare (default-cli) on project mercurial: Execution default-cli of goal org.apache.maven.plugins:maven-release-plugin:2.2.1:prepare failed: Failed to build parent project for org.jenkins-ci.plugins:mercurial:hpi:1.39-SNAPSHOT: Some problems were encountered while processing the POMs: [ERROR] [ERROR] Unresolveable build extension: Plugin org.jenkins-ci.tools:maven-hpi-plugin:1.74 or one of its dependencies could not be resolved: Could not find artifact org.jenkins-ci.tools:maven-hpi-plugin:jar:1.74 in central (CENTRAL_MIRROR/) @: 1 problem was encountered while building the effective model for org.jenkins-ci.plugins:plugin:1.461 [ERROR] [ERROR] Unresolveable build extension: Plugin org.jenkins-ci.tools:maven-hpi-plugin:1.74 or one of its dependencies could not be resolved: Could not find artifact org.jenkins-ci.tools:maven-hpi-plugin:jar:1.74 in central (CENTRAL_MIRROR/) @ {code} Indeed I think the error message is correct: {{plugin-1.400.pom}} (or again {{plugin-1.461.pom}}) refers to {{maven-hpi-plugin}} yet does not declare any {{pluginRepository}} in which it might be found. (Nor does its own parent.) Maven 2 succeeds in this case; apparently it does not care where the plugin came from. But Maven 3 as described in https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository does care. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13919) How do I submit my Jenkins plugin in Github
[ https://issues.jenkins-ci.org/browse/JENKINS-13919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jeff Li reassigned JENKINS-13919: - Assignee: Kohsuke Kawaguchi How do I submit my Jenkins plugin in Github --- Key: JENKINS-13919 URL: https://issues.jenkins-ci.org/browse/JENKINS-13919 Project: Jenkins Issue Type: New Feature Components: plugin Reporter: Jeff Li Assignee: Kohsuke Kawaguchi Hi, I develop a Jenkins plugin for blitz.io. It's already pushed to Github https://github.com/jeffli/blitz_io-jenkins-plugin . Based on this article, https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins , I should request some commit permission to https://github.com/jenkinsci so it can be hosted there? Please guide me through this process. Appreciated! Jeff -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13937) ArtifactDeployer 0.16 messes the filenames for Windows filesystems
Roger Myung created JENKINS-13937: - Summary: ArtifactDeployer 0.16 messes the filenames for Windows filesystems Key: JENKINS-13937 URL: https://issues.jenkins-ci.org/browse/JENKINS-13937 Project: Jenkins Issue Type: Bug Components: artifactdeployer Environment: artifactdeployer 0.16 Windows Reporter: Roger Myung Assignee: Gregory Boissinot We deploy our artifacts to a UNC path \\COMPUTERNAME\Artifacts\artifact.file With version 0.16, when a user tries to download this file, the file becomes _COMPUTERNAMEArtifactsartifact.file -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9392) Read-Only .war prevents Auto-Update
[ https://issues.jenkins-ci.org/browse/JENKINS-9392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163270#comment-163270 ] Andrew Erickson commented on JENKINS-9392: -- I just debugged why I couldn't auto-upgrade on the Mac... this functionality would seem handy for everyone. Read-Only .war prevents Auto-Update --- Key: JENKINS-9392 URL: https://issues.jenkins-ci.org/browse/JENKINS-9392 Project: Jenkins Issue Type: Improvement Components: update-center Environment: jenkins .401 Reporter: Brian Relph Priority: Minor If hudson.war is read-only, the auto-update link is not available. I am not sure how hudson.war got set to read-only, but it was an accident, and it took me awhile to figure out the problem. Would it be possible to add a message indicating why auto-update is not available? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13938) Mac installer should set owner of /Applications/Jenkins to 'jenkins' user (fix Mac auto-upgrade)
Andrew Erickson created JENKINS-13938: - Summary: Mac installer should set owner of /Applications/Jenkins to 'jenkins' user (fix Mac auto-upgrade) Key: JENKINS-13938 URL: https://issues.jenkins-ci.org/browse/JENKINS-13938 Project: Jenkins Issue Type: Improvement Components: other Affects Versions: current Reporter: Andrew Erickson Priority: Minor If this was done then Mac users could auto-upgrade. Currently the permissions are preventing this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13939) Workspace cleanup plugin causes Jenkins to consider a job as completed before it is actually done
Ben Sluis created JENKINS-13939: --- Summary: Workspace cleanup plugin causes Jenkins to consider a job as completed before it is actually done Key: JENKINS-13939 URL: https://issues.jenkins-ci.org/browse/JENKINS-13939 Project: Jenkins Issue Type: Bug Components: ws-cleanup Affects Versions: current Environment: Windows Server 2008 Reporter: Ben Sluis Assignee: vjuranek Attachments: BuildSteps.png The latest version (0.8) of the workspace cleanup plugin seems to cause Jenkins to think a job is complete before it actually finishes all post build steps. Going back to version 0.7 doesn't show this problem. Example: See attached BuildSteps.png 'Results' is a job that blocks when upstream jobs are running. Jobs A, B, C, and D trigger the downstream job 'Results' and pass their current build parameters (which are all the same) using the Parameterized Trigger plugin (v2.14). In the scenario where only one upstream job is still running (say all jobs completed except 'D'), the 'Results' job is blocked (waiting for job 'D'). This is correct. However, once job 'D' got to the workspace cleanup post build step in its job configuration, the downstream job 'Results' would get triggered as if all upstream jobs were completed. This is a problem. Then when job 'D' actually finishes cleaning up the workspace, another build of job 'Results' is triggered. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13637) Cannot release using M3
[ https://issues.jenkins-ci.org/browse/JENKINS-13637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163268#comment-163268 ] Joe Hansche edited comment on JENKINS-13637 at 5/29/12 6:34 PM: -@jglick, is there a workaround to resolve this issue? Or is the only way to fix it to install M2?- KK pointed me in the right direction: the problem was the missing {{profiles}} section of settings.xml. See https://wiki.jenkins-ci.org/display/JENKINS/Plugin+tutorial#Plugintutorial-SettingUpEnvironment was (Author: jhansche): @jglick, is there a workaround to resolve this issue? Or is the only way to fix it to install M2? Cannot release using M3 --- Key: JENKINS-13637 URL: https://issues.jenkins-ci.org/browse/JENKINS-13637 Project: Jenkins Issue Type: Bug Components: plugin Environment: Ubuntu, JDK 6 Reporter: jglick Labels: maven, release-plugin Given the {{mercurial}} plugin with parent {{org.jenkins-ci.plugins:plugin:1.400}}, but also reproducible with {{1.461}}, Maven 3 {{mvn -B release:prepare}} fails with {code} [INFO] Checking dependencies and plugins for snapshots ... [INFO] Transforming 'Jenkins Mercurial plugin'... Downloading: CENTRAL_MIRROR/org/jenkins-ci/tools/maven-hpi-plugin/1.74/maven-hpi-plugin-1.74.pom [WARNING] The POM for org.jenkins-ci.tools:maven-hpi-plugin:jar:1.74 is missing, no dependency information available Downloading: CENTRAL_MIRROR/org/jenkins-ci/tools/maven-hpi-plugin/1.74/maven-hpi-plugin-1.74.jar [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 5.310s [INFO] Finished at: Fri Apr 27 19:30:03 EDT 2012 [INFO] Final Memory: 10M/164M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.2.1:prepare (default-cli) on project mercurial: Execution default-cli of goal org.apache.maven.plugins:maven-release-plugin:2.2.1:prepare failed: Failed to build parent project for org.jenkins-ci.plugins:mercurial:hpi:1.39-SNAPSHOT: Some problems were encountered while processing the POMs: [ERROR] [ERROR] Unresolveable build extension: Plugin org.jenkins-ci.tools:maven-hpi-plugin:1.74 or one of its dependencies could not be resolved: Could not find artifact org.jenkins-ci.tools:maven-hpi-plugin:jar:1.74 in central (CENTRAL_MIRROR/) @: 1 problem was encountered while building the effective model for org.jenkins-ci.plugins:plugin:1.461 [ERROR] [ERROR] Unresolveable build extension: Plugin org.jenkins-ci.tools:maven-hpi-plugin:1.74 or one of its dependencies could not be resolved: Could not find artifact org.jenkins-ci.tools:maven-hpi-plugin:jar:1.74 in central (CENTRAL_MIRROR/) @ {code} Indeed I think the error message is correct: {{plugin-1.400.pom}} (or again {{plugin-1.461.pom}}) refers to {{maven-hpi-plugin}} yet does not declare any {{pluginRepository}} in which it might be found. (Nor does its own parent.) Maven 2 succeeds in this case; apparently it does not care where the plugin came from. But Maven 3 as described in https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository does care. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13896) Exception when multiple end markers present on page
[ https://issues.jenkins-ci.org/browse/JENKINS-13896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Hansche closed JENKINS-13896. - Assignee: Sampo Niskanen (was: Joe Hansche) Released as version 1.6 Exception when multiple end markers present on page --- Key: JENKINS-13896 URL: https://issues.jenkins-ci.org/browse/JENKINS-13896 Project: Jenkins Issue Type: Bug Components: confluence-publisher Reporter: Sampo Niskanen Assignee: Sampo Niskanen When using the Replace content between start/end tokens if the end marker exists in multiple places on the page, the first marker is selected even if it is before the start marker. This results in failure with the following stack trace: [confluence] Performing wiki edits: Replace content between start/end tokens ERROR: Publisher com.myyearbook.hudson.plugins.confluence.ConfluencePublisher aborted due to exception java.lang.StringIndexOutOfBoundsException at java.lang.AbstractStringBuilder.delete(AbstractStringBuilder.java:702) at java.lang.StringBuffer.delete(StringBuffer.java:373) at com.myyearbook.hudson.plugins.confluence.wiki.editors.BetweenTokensEditor.performEdits(BetweenTokensEditor.java:57) at com.myyearbook.hudson.plugins.confluence.wiki.editors.MarkupEditor.performReplacement(MarkupEditor.java:57) at com.myyearbook.hudson.plugins.confluence.ConfluencePublisher.performEdits(ConfluencePublisher.java:394) at com.myyearbook.hudson.plugins.confluence.ConfluencePublisher.performWikiReplacements(ConfluencePublisher.java:353) at com.myyearbook.hudson.plugins.confluence.ConfluencePublisher.perform(ConfluencePublisher.java:327) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:710) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:685) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:632) at hudson.model.Run.run(Run.java:1459) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) The fix for this is trivial, just search for the next end token *after* the start token. I.e. change line 45 in BetweenTokensEditor.java from final int end = content.indexOf(endMarkerToken); to final int end = content.indexOf(endMarkerToken, start); Ideally both start and end token is unique on the page, but for example when using the DIV macro to create a page portion to replace the end token is always /ac:rich-text-body/ac:macro. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13912) Add the ability to add custom header fields to emails
[ https://issues.jenkins-ci.org/browse/JENKINS-13912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Slide-O-Mix reassigned JENKINS-13912: - Assignee: Slide-O-Mix Add the ability to add custom header fields to emails - Key: JENKINS-13912 URL: https://issues.jenkins-ci.org/browse/JENKINS-13912 Project: Jenkins Issue Type: Improvement Components: email-ext Reporter: Dirk Kuypers Assignee: Slide-O-Mix IMHO it would be nice to be able to add custom header fields to emails. In our environment we are continuously building and testing different branches in parallel. Failing tests send out emails where filtering on custom header fields would add quite some comfort to the work of our developers.;-) Example: X-Branch: main X-BRanch: Version_2.60 and so on... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13912) Add the ability to add custom header fields to emails
[ https://issues.jenkins-ci.org/browse/JENKINS-13912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163272#comment-163272 ] Slide-O-Mix commented on JENKINS-13912: --- Once the new pre-send script feature is released, you should be able to do this using that pre-send script. See JENKINS-12421 for info. Add the ability to add custom header fields to emails - Key: JENKINS-13912 URL: https://issues.jenkins-ci.org/browse/JENKINS-13912 Project: Jenkins Issue Type: Improvement Components: email-ext Reporter: Dirk Kuypers Assignee: Slide-O-Mix IMHO it would be nice to be able to add custom header fields to emails. In our environment we are continuously building and testing different branches in parallel. Failing tests send out emails where filtering on custom header fields would add quite some comfort to the work of our developers.;-) Example: X-Branch: main X-BRanch: Version_2.60 and so on... -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13652) Support workflow steps as build actions and/or post-build notifiers
[ https://issues.jenkins-ci.org/browse/JENKINS-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-13652 started by Joe Hansche. Support workflow steps as build actions and/or post-build notifiers --- Key: JENKINS-13652 URL: https://issues.jenkins-ci.org/browse/JENKINS-13652 Project: Jenkins Issue Type: New Feature Components: jira Reporter: Joe Hansche Assignee: Joe Hansche The [Jira Issue Updater Plugin|https://wiki.jenkins-ci.org/display/JENKINS/Jira+Issue+Updater+Plugin] has a build step that can be used to issue workflow updates as part of a build. Unfortunately that plugin doesn't tie in with the JIRA Plugin, so you must manually enter the wsdl URL, username, and password every time the build step is used. Adding a build step would allow the workflow actions to be taken in series with an existing job configuration. Additionally, adding a notifier (post-Recorder, which is how the JiraIssueUpdater works), would allow the job to delay updating the workflow action until all other recorders have finished (if that is the desire). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13700) Build hangs during while Sending email
[ https://issues.jenkins-ci.org/browse/JENKINS-13700?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163273#comment-163273 ] Slide-O-Mix commented on JENKINS-13700: --- Can you post your build log with the exception detail? Build hangs during while Sending email Key: JENKINS-13700 URL: https://issues.jenkins-ci.org/browse/JENKINS-13700 Project: Jenkins Issue Type: Bug Components: core, email-ext Environment: OS: Master: Ubuntu 10.04 Slaves: OSX 1.7.3, Win2K8 Server, Win XP, Win2K3 Server Jenkins: 1.424.1 Plugins: Email-ext plugin: 2.14.1 Configuration Slicing plugin: 1.28.1 Jenkins GIT plugin: 1.1.18 Perforce Plugin: 1.3.9 Reporter: crwong When building on the OSX slave, the build will get to the point where the console says that it is sending email, and it stays there. If you look at the list of executors, the progress bar shows that the build is still on progress. If you look at the job's status page, it looks like the job has completed, and it is no longer running. Clicking on the Stop build button next to the job in the Build Executors Status section, does nothing. The only way to clear the executor is to restart Jenkins. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13940) I'm trying to authenticate the Jenkins command line (CLI) and the system returns an error message (user authentication with AD), authenticates through the GUI normally.
Jesiel Moraes da Conceição created JENKINS-13940: Summary: I'm trying to authenticate the Jenkins command line (CLI) and the system returns an error message (user authentication with AD), authenticates through the GUI normally. Key: JENKINS-13940 URL: https://issues.jenkins-ci.org/browse/JENKINS-13940 Project: Jenkins Issue Type: Bug Components: accurev, cli Affects Versions: current Environment: Windows Server 2008 R2 Standard Reporter: Jesiel Moraes da Conceição Assignee: Scott Tatum Priority: Blocker I'm trying to authenticate the Jenkins command line (CLI) and the system returns an error message (user authentication with AD), authenticates through the GUI normally. Under the command and the error: c:\java -jar jenkins-cli.jar -s http://correcaobuild login --username jesiel Password: hudson.security.UserMayOrMayNotExistException: Unable to retrieve the user information without bind DN/password configured at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:297) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:185) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:133) at hudson.plugins.active_directory.AbstractActiveDirectoryAuthenticationProvider.loadUserByUsername(AbstractActiveDirectoryAuthenticationProvider.java:27) at hudson.plugins.active_directory.ActiveDirectorySecurityRealm.loadUserByUsername(ActiveDirectorySecurityRealm.java:582) at hudson.cli.ClientAuthenticationCache.set(ClientAuthenticationCache.java:94) at hudson.cli.LoginCommand.run(LoginCommand.java:37) at hudson.cli.CLICommand.main(CLICommand.java:228) at hudson.cli.CliManagerImpl.main(CliManagerImpl.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:274) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:255) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:215) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at hudson.cli.CliManagerImpl$1.call(CliManagerImpl.java:63) at hudson.remoting.InterceptingExecutorService$2.call(InterceptingExecutorService.java:95) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13102) Build hangs trying to send email if an email address isn't defined in Active Directory
[ https://issues.jenkins-ci.org/browse/JENKINS-13102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163274#comment-163274 ] Slide-O-Mix commented on JENKINS-13102: --- Sorry, the fix above won't stop the time issue, it will only continue if resolution for a specific address fails. I am still investigating how to work around the resolution issue. Build hangs trying to send email if an email address isn't defined in Active Directory -- Key: JENKINS-13102 URL: https://issues.jenkins-ci.org/browse/JENKINS-13102 Project: Jenkins Issue Type: Bug Components: email-ext Environment: Jenkins - 1.455 email-ext 2.18 perforce plugin - 1.3.9 AD plugin - 1.26 Windows 2003 master Linux x64 slave Reporter: aflat I have some builds that hang when the perforce user is build. In perforce build has a valid email. In Active Directory there is no email for the build user. I'm fixing this to get around the issue, so I may not be able to reproduce this for long(I'm not the IT guy). I don't know why perforce is trying to get the email from AD, so that may be a perforce plugin bug. Here is the stack trace from the jenkins.err log. The build hangs when trying to send email, you can try to cancel the job, but the job never goes away. Eventually the job does time out, but it can take over 8 hours(4 domains to search through) javax.naming.NamingException: [LDAP: error code 1 - : LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece ]; remaining name 'DC=company,DC=com' at com.sun.jndi.ldap.LdapCtx.mapErrorCode(Unknown Source) at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source) at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source) at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source) at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source) at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown Source) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source) at com.sun.jndi.toolkit.ctx.PartialCompositeDirContext.search(Unknown Source) at hudson.plugins.active_directory.LDAPSearchBuilder.search(LDAPSearchBuilder.java:52) at hudson.plugins.active_directory.LDAPSearchBuilder.searchOne(LDAPSearchBuilder.java:42) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:191) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:130) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:95) at hudson.plugins.active_directory.AbstractActiveDirectoryAuthenticationProvider.loadUserByUsername(AbstractActiveDirectoryAuthenticationProvider.java:27) at hudson.plugins.active_directory.ActiveDirectoryMailAddressResolverImpl.findMailAddressFor(ActiveDirectoryMailAddressResolverImpl.java:31) at hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:100) at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:514) at hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:335) at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:255) at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:247) at hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:207) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656) at hudson.model.Build$RunnerImpl.cleanUp(Build.java:171) at hudson.model.Run.run(Run.java:1454) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13940) I'm trying to authenticate the Jenkins command line (CLI) and the system returns an error message (user authentication with AD), but the GUI works.
[ https://issues.jenkins-ci.org/browse/JENKINS-13940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-13940 started by Scott Tatum. I'm trying to authenticate the Jenkins command line (CLI) and the system returns an error message (user authentication with AD), but the GUI works. --- Key: JENKINS-13940 URL: https://issues.jenkins-ci.org/browse/JENKINS-13940 Project: Jenkins Issue Type: Bug Components: accurev, cli Affects Versions: current Environment: Windows Server 2008 R2 Standard Reporter: Jesiel Moraes da Conceição Assignee: Scott Tatum Priority: Blocker I'm trying to authenticate the Jenkins command line (CLI) and the system returns an error message (user authentication with AD), authenticates through the GUI normally. Under the command and the error: c:\java -jar jenkins-cli.jar -s http://correcaobuild login --username jesiel Password: hudson.security.UserMayOrMayNotExistException: Unable to retrieve the user information without bind DN/password configured at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:297) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:185) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:133) at hudson.plugins.active_directory.AbstractActiveDirectoryAuthenticationProvider.loadUserByUsername(AbstractActiveDirectoryAuthenticationProvider.java:27) at hudson.plugins.active_directory.ActiveDirectorySecurityRealm.loadUserByUsername(ActiveDirectorySecurityRealm.java:582) at hudson.cli.ClientAuthenticationCache.set(ClientAuthenticationCache.java:94) at hudson.cli.LoginCommand.run(LoginCommand.java:37) at hudson.cli.CLICommand.main(CLICommand.java:228) at hudson.cli.CliManagerImpl.main(CliManagerImpl.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:274) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:255) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:215) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at hudson.cli.CliManagerImpl$1.call(CliManagerImpl.java:63) at hudson.remoting.InterceptingExecutorService$2.call(InterceptingExecutorService.java:95) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13940) I'm trying to authenticate the Jenkins command line (CLI) and the system returns an error message (user authentication with AD), but the GUI works.
[ https://issues.jenkins-ci.org/browse/JENKINS-13940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesiel Moraes da Conceição updated JENKINS-13940: - Summary: I'm trying to authenticate the Jenkins command line (CLI) and the system returns an error message (user authentication with AD), but the GUI works. (was: I'm trying to authenticate the Jenkins command line (CLI) and the system returns an error message (user authentication with AD), authenticates through the GUI normally.) I'm trying to authenticate the Jenkins command line (CLI) and the system returns an error message (user authentication with AD), but the GUI works. --- Key: JENKINS-13940 URL: https://issues.jenkins-ci.org/browse/JENKINS-13940 Project: Jenkins Issue Type: Bug Components: accurev, cli Affects Versions: current Environment: Windows Server 2008 R2 Standard Reporter: Jesiel Moraes da Conceição Assignee: Scott Tatum Priority: Blocker I'm trying to authenticate the Jenkins command line (CLI) and the system returns an error message (user authentication with AD), authenticates through the GUI normally. Under the command and the error: c:\java -jar jenkins-cli.jar -s http://correcaobuild login --username jesiel Password: hudson.security.UserMayOrMayNotExistException: Unable to retrieve the user information without bind DN/password configured at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:297) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:185) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:133) at hudson.plugins.active_directory.AbstractActiveDirectoryAuthenticationProvider.loadUserByUsername(AbstractActiveDirectoryAuthenticationProvider.java:27) at hudson.plugins.active_directory.ActiveDirectorySecurityRealm.loadUserByUsername(ActiveDirectorySecurityRealm.java:582) at hudson.cli.ClientAuthenticationCache.set(ClientAuthenticationCache.java:94) at hudson.cli.LoginCommand.run(LoginCommand.java:37) at hudson.cli.CLICommand.main(CLICommand.java:228) at hudson.cli.CliManagerImpl.main(CliManagerImpl.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:274) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:255) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:215) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at hudson.cli.CliManagerImpl$1.call(CliManagerImpl.java:63) at hudson.remoting.InterceptingExecutorService$2.call(InterceptingExecutorService.java:95) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13940) I'm trying to authenticate the Jenkins command line (CLI) and the system returns an error message (user authentication with AD), but the GUI works.
[ https://issues.jenkins-ci.org/browse/JENKINS-13940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jesiel Moraes da Conceição updated JENKINS-13940: - Component/s: active-directory (was: accurev) I'm trying to authenticate the Jenkins command line (CLI) and the system returns an error message (user authentication with AD), but the GUI works. --- Key: JENKINS-13940 URL: https://issues.jenkins-ci.org/browse/JENKINS-13940 Project: Jenkins Issue Type: Bug Components: active-directory, cli Affects Versions: current Environment: Windows Server 2008 R2 Standard Reporter: Jesiel Moraes da Conceição Assignee: Scott Tatum Priority: Blocker I'm trying to authenticate the Jenkins command line (CLI) and the system returns an error message (user authentication with AD), authenticates through the GUI normally. Under the command and the error: c:\java -jar jenkins-cli.jar -s http://correcaobuild login --username jesiel Password: hudson.security.UserMayOrMayNotExistException: Unable to retrieve the user information without bind DN/password configured at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:297) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:185) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:133) at hudson.plugins.active_directory.AbstractActiveDirectoryAuthenticationProvider.loadUserByUsername(AbstractActiveDirectoryAuthenticationProvider.java:27) at hudson.plugins.active_directory.ActiveDirectorySecurityRealm.loadUserByUsername(ActiveDirectorySecurityRealm.java:582) at hudson.cli.ClientAuthenticationCache.set(ClientAuthenticationCache.java:94) at hudson.cli.LoginCommand.run(LoginCommand.java:37) at hudson.cli.CLICommand.main(CLICommand.java:228) at hudson.cli.CliManagerImpl.main(CliManagerImpl.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:274) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:255) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:215) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at hudson.cli.CliManagerImpl$1.call(CliManagerImpl.java:63) at hudson.remoting.InterceptingExecutorService$2.call(InterceptingExecutorService.java:95) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13940) I'm trying to authenticate the Jenkins command line (CLI) and the system returns an error message (user authentication with AD), but the GUI works.
[ https://issues.jenkins-ci.org/browse/JENKINS-13940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-13940 stopped by Jesiel Moraes da Conceição. I'm trying to authenticate the Jenkins command line (CLI) and the system returns an error message (user authentication with AD), but the GUI works. --- Key: JENKINS-13940 URL: https://issues.jenkins-ci.org/browse/JENKINS-13940 Project: Jenkins Issue Type: Bug Components: accurev, cli Affects Versions: current Environment: Windows Server 2008 R2 Standard Reporter: Jesiel Moraes da Conceição Assignee: Scott Tatum Priority: Blocker I'm trying to authenticate the Jenkins command line (CLI) and the system returns an error message (user authentication with AD), authenticates through the GUI normally. Under the command and the error: c:\java -jar jenkins-cli.jar -s http://correcaobuild login --username jesiel Password: hudson.security.UserMayOrMayNotExistException: Unable to retrieve the user information without bind DN/password configured at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:297) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:185) at hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider.retrieveUser(ActiveDirectoryUnixAuthenticationProvider.java:133) at hudson.plugins.active_directory.AbstractActiveDirectoryAuthenticationProvider.loadUserByUsername(AbstractActiveDirectoryAuthenticationProvider.java:27) at hudson.plugins.active_directory.ActiveDirectorySecurityRealm.loadUserByUsername(ActiveDirectorySecurityRealm.java:582) at hudson.cli.ClientAuthenticationCache.set(ClientAuthenticationCache.java:94) at hudson.cli.LoginCommand.run(LoginCommand.java:37) at hudson.cli.CLICommand.main(CLICommand.java:228) at hudson.cli.CliManagerImpl.main(CliManagerImpl.java:92) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:274) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:255) at hudson.remoting.RemoteInvocationHandler$RPCRequest.call(RemoteInvocationHandler.java:215) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at hudson.cli.CliManagerImpl$1.call(CliManagerImpl.java:63) at hudson.remoting.InterceptingExecutorService$2.call(InterceptingExecutorService.java:95) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13735) Jenkins starts wrong slave for job restricted to specific one
[ https://issues.jenkins-ci.org/browse/JENKINS-13735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-13735. Resolution: Fixed Jenkins starts wrong slave for job restricted to specific one - Key: JENKINS-13735 URL: https://issues.jenkins-ci.org/browse/JENKINS-13735 Project: Jenkins Issue Type: Bug Components: master-slave, slave-setup, vsphere-cloud Affects Versions: current Environment: Jenkins 1.463 under Tomcat6 on Linux (SLES 11), Windows XP slave VMs controlled via vSphere Cloud plugin Reporter: Marco Lehnort Assignee: Kohsuke Kawaguchi Labels: slave I'm using the following setup: - WinXP slaves A,B,C - jobs jA, jB, jC, tied to slaves A,B,C respectively using Restrict where this job can run Assume all slaves are disconnected and powered off, no builds are queued. When starting a build manually, say jC, the following will happen: - job jC will be scheduled and also displayed accordingly in the build queue - tooltip will say it's waiting because slave C is offline - next, slave A is powered on by Jenkins and connection is established - jC will not be started, Jenkins seems to honor the restriction correctly - after some idle time, Jenkins realizes the slave is idle and causes shut down - then, same procedure happens with slave B - on occasion, next one is slave A again - finally (on good luck?) slave C happens to be started - jC is executed It is possible that jC is waiting for hours (indefinitely?), because the required slave is not powered on. I also observed this behaviour using a time-trigger instead of manual trigger, so I assume it is independent of the type of trigger. Occasionally it also happens that the correct slave is powered up right away, but that seems to happen by chance. The concrete pattern is not obvious to me. Note that the component selection above is just my best guess. Cheers, Marco -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13735) Jenkins starts wrong slave for job restricted to specific one
[ https://issues.jenkins-ci.org/browse/JENKINS-13735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163275#comment-163275 ] SCM/JIRA link daemon commented on JENKINS-13735: Code changed in jenkins User: fma1977 Path: changelog.html core/src/main/java/hudson/slaves/RetentionStrategy.java http://jenkins-ci.org/commit/jenkins/71ad43a141ddeb62d6df4a13b8513c42d73c0b82 Log: [FIXED JENKINS-13735] Added test whether the currently checked slave computer actually can take the buildable item before flagging it as needed (avoids powering up and connecting to slaves for jobs they can't build). Jenkins starts wrong slave for job restricted to specific one - Key: JENKINS-13735 URL: https://issues.jenkins-ci.org/browse/JENKINS-13735 Project: Jenkins Issue Type: Bug Components: master-slave, slave-setup, vsphere-cloud Affects Versions: current Environment: Jenkins 1.463 under Tomcat6 on Linux (SLES 11), Windows XP slave VMs controlled via vSphere Cloud plugin Reporter: Marco Lehnort Assignee: Kohsuke Kawaguchi Labels: slave I'm using the following setup: - WinXP slaves A,B,C - jobs jA, jB, jC, tied to slaves A,B,C respectively using Restrict where this job can run Assume all slaves are disconnected and powered off, no builds are queued. When starting a build manually, say jC, the following will happen: - job jC will be scheduled and also displayed accordingly in the build queue - tooltip will say it's waiting because slave C is offline - next, slave A is powered on by Jenkins and connection is established - jC will not be started, Jenkins seems to honor the restriction correctly - after some idle time, Jenkins realizes the slave is idle and causes shut down - then, same procedure happens with slave B - on occasion, next one is slave A again - finally (on good luck?) slave C happens to be started - jC is executed It is possible that jC is waiting for hours (indefinitely?), because the required slave is not powered on. I also observed this behaviour using a time-trigger instead of manual trigger, so I assume it is independent of the type of trigger. Occasionally it also happens that the correct slave is powered up right away, but that seems to happen by chance. The concrete pattern is not obvious to me. Note that the component selection above is just my best guess. Cheers, Marco -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13937) ArtifactDeployer 0.16 messes the filenames for Windows filesystems
[ https://issues.jenkins-ci.org/browse/JENKINS-13937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163276#comment-163276 ] Gregory Boissinot commented on JENKINS-13937: - Is the issue occurs when the user clicks 'Deployed Artifacts' section in the Jenkins main page? ArtifactDeployer 0.16 messes the filenames for Windows filesystems -- Key: JENKINS-13937 URL: https://issues.jenkins-ci.org/browse/JENKINS-13937 Project: Jenkins Issue Type: Bug Components: artifactdeployer Environment: artifactdeployer 0.16 Windows Reporter: Roger Myung Assignee: Gregory Boissinot We deploy our artifacts to a UNC path \\COMPUTERNAME\Artifacts\artifact.file With version 0.16, when a user tries to download this file, the file becomes _COMPUTERNAMEArtifactsartifact.file -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13941) Glowing green balls have non-transparent background
Leo Shklovskii created JENKINS-13941: Summary: Glowing green balls have non-transparent background Key: JENKINS-13941 URL: https://issues.jenkins-ci.org/browse/JENKINS-13941 Project: Jenkins Issue Type: Bug Components: greenballs Affects Versions: current Reporter: Leo Shklovskii Assignee: asgeirn Attachments: ugly.jpg In version 1.12. Green balls while they're glowing on and off during a running build don't have any transparency so they look quite ugly when you have the row highlighted. See attached image. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13496) Add more mimetypes recognized by default
[ https://issues.jenkins-ci.org/browse/JENKINS-13496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-13496. Resolution: Fixed Add more mimetypes recognized by default Key: JENKINS-13496 URL: https://issues.jenkins-ci.org/browse/JENKINS-13496 Project: Jenkins Issue Type: Improvement Components: core Reporter: Arnaud Héritier Assignee: Arnaud Héritier Nowadays Jenkins declares only few mimetypes : https://github.com/jenkinsci/jenkins/blob/master/war/src/main/webapp/WEB-INF/web.xml The issue is that the real list of mimetypes recognized depends a lot of the container used to host jenkins. There is a large list of choices managed by Tomcat but it is really poor for winstone and thus when we are browsing a workspace we may have various issues on files like PDF and co. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13496) Add more mimetypes recognized by default
[ https://issues.jenkins-ci.org/browse/JENKINS-13496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163277#comment-163277 ] SCM/JIRA link daemon commented on JENKINS-13496: Code changed in jenkins User: Kohsuke Kawaguchi Path: src/java/winstone/mime.properties http://jenkins-ci.org/commit/winstone/351d12e40cc38edcfc87a89db651fb140e53cf1b Log: [FIXED JENKINS-13496] Added more MIME type mappings from https://github.com/jenkinsci/jenkins/pull/447 Add more mimetypes recognized by default Key: JENKINS-13496 URL: https://issues.jenkins-ci.org/browse/JENKINS-13496 Project: Jenkins Issue Type: Improvement Components: core Reporter: Arnaud Héritier Assignee: Arnaud Héritier Nowadays Jenkins declares only few mimetypes : https://github.com/jenkinsci/jenkins/blob/master/war/src/main/webapp/WEB-INF/web.xml The issue is that the real list of mimetypes recognized depends a lot of the container used to host jenkins. There is a large list of choices managed by Tomcat but it is really poor for winstone and thus when we are browsing a workspace we may have various issues on files like PDF and co. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12854) Large Artifacts can not be downloaded over WebInterface
[ https://issues.jenkins-ci.org/browse/JENKINS-12854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163278#comment-163278 ] SCM/JIRA link daemon commented on JENKINS-12854: Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html war/pom.xml http://jenkins-ci.org/commit/jenkins/e6a8d5e6449161a954dfe9998763906923555650 Log: [FIXED JENKINS-13496 JENKINS-12854] Integrated the newer version of Winstone. Compare: https://github.com/jenkinsci/jenkins/compare/71ad43a...e6a8d5e Large Artifacts can not be downloaded over WebInterface --- Key: JENKINS-12854 URL: https://issues.jenkins-ci.org/browse/JENKINS-12854 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Server: Win XP SP3 32-Bit Jenkins 1.451 Client: Win XP SP3 32- Bit Browser: Firefox 10.0.2 Reporter: Andre Gross Assignee: Andre Gross Fix For: current Attachments: jenkins.err.log I create an ISO which is around 3GB. When I try to access it through the web interface I get the following error in FireFox: Die Dateien unter http://wxde423hc4jw:8080/job/600_CreateSoMachineISO/lastSuccessfulBuild/artifact/SoMachine-3.1.1-12.02.22.03.iso konnten nicht gefunden werden. It says something like File not found. I also attached the jenkins error log which shows an exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13496) Add more mimetypes recognized by default
[ https://issues.jenkins-ci.org/browse/JENKINS-13496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163279#comment-163279 ] SCM/JIRA link daemon commented on JENKINS-13496: Code changed in jenkins User: Kohsuke Kawaguchi Path: changelog.html war/pom.xml http://jenkins-ci.org/commit/jenkins/e6a8d5e6449161a954dfe9998763906923555650 Log: [FIXED JENKINS-13496 JENKINS-12854] Integrated the newer version of Winstone. Compare: https://github.com/jenkinsci/jenkins/compare/71ad43a...e6a8d5e Add more mimetypes recognized by default Key: JENKINS-13496 URL: https://issues.jenkins-ci.org/browse/JENKINS-13496 Project: Jenkins Issue Type: Improvement Components: core Reporter: Arnaud Héritier Assignee: Arnaud Héritier Nowadays Jenkins declares only few mimetypes : https://github.com/jenkinsci/jenkins/blob/master/war/src/main/webapp/WEB-INF/web.xml The issue is that the real list of mimetypes recognized depends a lot of the container used to host jenkins. There is a large list of choices managed by Tomcat but it is really poor for winstone and thus when we are browsing a workspace we may have various issues on files like PDF and co. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13863) MSBuild is unable to build projects in a different directory
[ https://issues.jenkins-ci.org/browse/JENKINS-13863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163280#comment-163280 ] Gregory Boissinot commented on JENKINS-13863: - Do you know a command line argument for msbuild to specify another path? MSBuild is unable to build projects in a different directory Key: JENKINS-13863 URL: https://issues.jenkins-ci.org/browse/JENKINS-13863 Project: Jenkins Issue Type: Bug Components: msbuild Affects Versions: current Environment: MS Windows Server 2008 Reporter: Aaron Laws Assignee: kdsweeney Priority: Minor Labels: path, plugin Attachments: badbuild.txt, badconfig.PNG, goodbuild.txt, goodconfig.PNG I use SVN to checkout a project to {{.\proj\}} and a dependency to {{.\dep\}}. The {{.sln}} file is at {{.\proj\proj.sln}}. I us the MsBuild plugin with the setting MsBuild Build File = {{proj\proj.sln}} (or a number of variants such as {{.\proj\proj.sln}}). Msbuild fails with {{MSB1009: Project file does not exist.}} However, running a similar command manually succeeds. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13637) Cannot release using M3
[ https://issues.jenkins-ci.org/browse/JENKINS-13637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163281#comment-163281 ] jglick commented on JENKINS-13637: -- Activating the Jenkins repos by default, which would affect _any_ Maven projects, does not seem like a reasonable workaround; passing {{\-Pjenkins}} during {{release:prepare}} would be an unpleasant but unacceptable workaround if that sufficed. A proper fix would be in {{plugin-*.pom}} to declare the {{pluginRepository}} it needs (or avoid using {{maven-hpi-plugin}} if it does not), so that the release plugin works without special configuration. Cannot release using M3 --- Key: JENKINS-13637 URL: https://issues.jenkins-ci.org/browse/JENKINS-13637 Project: Jenkins Issue Type: Bug Components: plugin Environment: Ubuntu, JDK 6 Reporter: jglick Labels: maven, release-plugin Given the {{mercurial}} plugin with parent {{org.jenkins-ci.plugins:plugin:1.400}}, but also reproducible with {{1.461}}, Maven 3 {{mvn -B release:prepare}} fails with {code} [INFO] Checking dependencies and plugins for snapshots ... [INFO] Transforming 'Jenkins Mercurial plugin'... Downloading: CENTRAL_MIRROR/org/jenkins-ci/tools/maven-hpi-plugin/1.74/maven-hpi-plugin-1.74.pom [WARNING] The POM for org.jenkins-ci.tools:maven-hpi-plugin:jar:1.74 is missing, no dependency information available Downloading: CENTRAL_MIRROR/org/jenkins-ci/tools/maven-hpi-plugin/1.74/maven-hpi-plugin-1.74.jar [INFO] [INFO] BUILD FAILURE [INFO] [INFO] Total time: 5.310s [INFO] Finished at: Fri Apr 27 19:30:03 EDT 2012 [INFO] Final Memory: 10M/164M [INFO] [ERROR] Failed to execute goal org.apache.maven.plugins:maven-release-plugin:2.2.1:prepare (default-cli) on project mercurial: Execution default-cli of goal org.apache.maven.plugins:maven-release-plugin:2.2.1:prepare failed: Failed to build parent project for org.jenkins-ci.plugins:mercurial:hpi:1.39-SNAPSHOT: Some problems were encountered while processing the POMs: [ERROR] [ERROR] Unresolveable build extension: Plugin org.jenkins-ci.tools:maven-hpi-plugin:1.74 or one of its dependencies could not be resolved: Could not find artifact org.jenkins-ci.tools:maven-hpi-plugin:jar:1.74 in central (CENTRAL_MIRROR/) @: 1 problem was encountered while building the effective model for org.jenkins-ci.plugins:plugin:1.461 [ERROR] [ERROR] Unresolveable build extension: Plugin org.jenkins-ci.tools:maven-hpi-plugin:1.74 or one of its dependencies could not be resolved: Could not find artifact org.jenkins-ci.tools:maven-hpi-plugin:jar:1.74 in central (CENTRAL_MIRROR/) @ {code} Indeed I think the error message is correct: {{plugin-1.400.pom}} (or again {{plugin-1.461.pom}}) refers to {{maven-hpi-plugin}} yet does not declare any {{pluginRepository}} in which it might be found. (Nor does its own parent.) Maven 2 succeeds in this case; apparently it does not care where the plugin came from. But Maven 3 as described in https://cwiki.apache.org/MAVEN/maven-3x-compatibility-notes.html#Maven3.xCompatibilityNotes-ResolutionfromLocalRepository does care. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13814) java.lang.OutOfMemoryError exception when getting the remote log
[ https://issues.jenkins-ci.org/browse/JENKINS-13814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163282#comment-163282 ] James Gustafson commented on JENKINS-13814: --- The fixes in the latest 2.4 Snapshot work for my build now. Thanks a lot! java.lang.OutOfMemoryError exception when getting the remote log Key: JENKINS-13814 URL: https://issues.jenkins-ci.org/browse/JENKINS-13814 Project: Jenkins Issue Type: Bug Components: cvs Environment: Jenkins 1.464 on Windows 7 64-bit, 12GB RAM; CVS Plug-in 2.4-SNAPSHOT Reporter: James Gustafson Assignee: Michael Clarke Labels: cvs, exception, memory We are getting a java.lang.OutOfMemoryError exception when getting the remote log. {quote} Started by an SCM change Building in workspace C:\x\workspace\project_name_here cvs checkout -r BRANCH_NAME_HERE -D 16 May 2012 23:27:38 -0700 -d path\projects path/projects cvs checkout: Updating path\projects cvs checkout: Updating path\projects/dir1 cvs checkout: Updating path\projects/dir2/dirA ... (about 7,224 directories) ... cvs checkout: Updating path\projects/dirN cvs rlog: Logging path\projects ... (about 7,224 directories) ... cvs rlog: Logging path\projects/dirN FATAL: Java heap space java.lang.OutOfMemoryError: Java heap space at java.lang.StringCoding$StringDecoder.decode(Unknown Source) at java.lang.StringCoding.decode(Unknown Source) at java.lang.StringCoding.decode(Unknown Source) at java.lang.String.init(Unknown Source) at java.io.ByteArrayOutputStream.toString(Unknown Source) at hudson.scm.CVSSCM.getRemoteLogForModule(CVSSCM.java:540) at hudson.scm.CVSSCM.calculateChangeLog(CVSSCM.java:415) at hudson.scm.CVSSCM.checkout(CVSSCM.java:825) at hudson.model.AbstractProject.checkout(AbstractProject.java:1218) at hudson.model.AbstractBuild$AbstractRunner.checkout(AbstractBuild.java:586) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:475) at hudson.model.Run.run(Run.java:1434) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) {quote} Some notes: - The path/ and path\ comes from the Remote Name/Local Name settings solution from Issue JENKINS-13264 - We are using Jenkins 1.464 with the 2.4-SNAPSHOT version of the CVS plugin, but may not have been caused by this specific version - The arguments setting in the jenkins.xml file currently has -Xms1024m (anything larger and Jenkins service won't start) - The CVS module has many legacy projects spread out, and thus, contains more than 7,000 directories and many more files - Things had worked with the 1.6 plug-in CVSNT client, but it also occasionally timed out getting the changelog, hence our testing of the 2.x plug-ins -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-5450) Clicking History from the left bar in a test result history page results in 404
[ https://issues.jenkins-ci.org/browse/JENKINS-5450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yusuf Burmawala reopened JENKINS-5450: -- Assignee: Kohsuke Kawaguchi Hi Kohsuke san, I could reproduce this issue while running Jenkins version 1.447.1 under Tomcat6. I am unable to access the old builds by clicking on the More link and have to keep changing the build numbers in the URL. Can you please assist me in resolving the problem? Thanks. Br, Yusuf Clicking History from the left bar in a test result history page results in 404 - Key: JENKINS-5450 URL: https://issues.jenkins-ci.org/browse/JENKINS-5450 Project: Jenkins Issue Type: Bug Components: gui Reporter: Kohsuke Kawaguchi Assignee: Kohsuke Kawaguchi If I click History from http://deadlock.netbeans.org/hudson/job/trunk/7635/testReport/history/ , I'm taken to http://deadlock.netbeans.org/hudson/job/trunk/7635/testReport/history/history , which is 404. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9688) Build runs on master without executor and get stuck
[ https://issues.jenkins-ci.org/browse/JENKINS-9688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jose Sa updated JENKINS-9688: - Attachment: job_time_null.png The problem still occurs in 1.458 see: !job_time_null.png! We have multiple jobs using the same lock representing a test environment, but without any quiet period. These jobs are not meant to run on master, but on a build slave, but in the build status it shows: Started 1 day 14 hr ago Build is being executed for null on master Maybe activating the default quiet period (30 seconds) will help in this situation. Build runs on master without executor and get stuck --- Key: JENKINS-9688 URL: https://issues.jenkins-ci.org/browse/JENKINS-9688 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Reporter: protocol7b Attachments: job_time_null.png In the ASF Jenkins, we do not allow builds to run on master. Thus, we have set the number of executors on master to zero. Even so, one build recently (https://builds.apache.org/hudson/job/Axis2/774/) got assigned to run on master. The build is configured with a label to run on one of the slaves, but somehow Jenkins assigned it incorrectly. Running on master also meant it got stuck, presumably due to the lack of executors, without any way of stopping it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-3969) Status ball images should have transparent background
[ https://issues.jenkins-ci.org/browse/JENKINS-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163285#comment-163285 ] SCM/JIRA link daemon commented on JENKINS-3969: --- Code changed in jenkins User: Ulli Hafner Path: core/src/main/resources/hudson/model/ExternalJob/sidepanel.jelly core/src/main/resources/hudson/model/ExternalRun/sidepanel.jelly http://jenkins-ci.org/commit/external-monitor-job-plugin/33dafa6ebbd676c167982846707aceabd1bf0714 Log: [FIXED JENKINS-3969] Replaced all gif images with corresponding png images. Originally-Committed-As: a4ba7bd268422e4ca7249e137b9dc0b6a20a84c0 Status ball images should have transparent background - Key: JENKINS-3969 URL: https://issues.jenkins-ci.org/browse/JENKINS-3969 Project: Jenkins Issue Type: Bug Components: gui Affects Versions: current Environment: Platform: All, OS: All Reporter: cristalp Assignee: Ulli Hafner Priority: Trivial Attachments: screenshot.png, screenshot2.png, wrong_status_ball.png I use the Emotional Hudson plugin, which shows the image of Hudson as a background of the build history. However, the status balls don't have a transparent background, which makes the whole thing look a bit ugly. Just cosmetics... :-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13652) Support workflow steps as build actions and/or post-build notifiers
[ https://issues.jenkins-ci.org/browse/JENKINS-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on JENKINS-13652 stopped by Joe Hansche. Support workflow steps as build actions and/or post-build notifiers --- Key: JENKINS-13652 URL: https://issues.jenkins-ci.org/browse/JENKINS-13652 Project: Jenkins Issue Type: New Feature Components: jira Reporter: Joe Hansche Assignee: Joe Hansche The [Jira Issue Updater Plugin|https://wiki.jenkins-ci.org/display/JENKINS/Jira+Issue+Updater+Plugin] has a build step that can be used to issue workflow updates as part of a build. Unfortunately that plugin doesn't tie in with the JIRA Plugin, so you must manually enter the wsdl URL, username, and password every time the build step is used. Adding a build step would allow the workflow actions to be taken in series with an existing job configuration. Additionally, adding a notifier (post-Recorder, which is how the JiraIssueUpdater works), would allow the job to delay updating the workflow action until all other recorders have finished (if that is the desire). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13652) Support workflow steps as build actions and/or post-build notifiers
[ https://issues.jenkins-ci.org/browse/JENKINS-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Hansche resolved JENKINS-13652. --- Resolution: Fixed Pull request submitted: https://github.com/jenkinsci/jira-plugin/pull/10 Support workflow steps as build actions and/or post-build notifiers --- Key: JENKINS-13652 URL: https://issues.jenkins-ci.org/browse/JENKINS-13652 Project: Jenkins Issue Type: New Feature Components: jira Reporter: Joe Hansche Assignee: Joe Hansche The [Jira Issue Updater Plugin|https://wiki.jenkins-ci.org/display/JENKINS/Jira+Issue+Updater+Plugin] has a build step that can be used to issue workflow updates as part of a build. Unfortunately that plugin doesn't tie in with the JIRA Plugin, so you must manually enter the wsdl URL, username, and password every time the build step is used. Adding a build step would allow the workflow actions to be taken in series with an existing job configuration. Additionally, adding a notifier (post-Recorder, which is how the JiraIssueUpdater works), would allow the job to delay updating the workflow action until all other recorders have finished (if that is the desire). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13652) Support workflow steps as build actions and/or post-build notifiers
[ https://issues.jenkins-ci.org/browse/JENKINS-13652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Hansche reassigned JENKINS-13652: - Assignee: olamy (was: Joe Hansche) Support workflow steps as build actions and/or post-build notifiers --- Key: JENKINS-13652 URL: https://issues.jenkins-ci.org/browse/JENKINS-13652 Project: Jenkins Issue Type: New Feature Components: jira Reporter: Joe Hansche Assignee: olamy The [Jira Issue Updater Plugin|https://wiki.jenkins-ci.org/display/JENKINS/Jira+Issue+Updater+Plugin] has a build step that can be used to issue workflow updates as part of a build. Unfortunately that plugin doesn't tie in with the JIRA Plugin, so you must manually enter the wsdl URL, username, and password every time the build step is used. Adding a build step would allow the workflow actions to be taken in series with an existing job configuration. Additionally, adding a notifier (post-Recorder, which is how the JiraIssueUpdater works), would allow the job to delay updating the workflow action until all other recorders have finished (if that is the desire). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9009) Slave name with a quote breaks matrix build label axis
[ https://issues.jenkins-ci.org/browse/JENKINS-9009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163288#comment-163288 ] SCM/JIRA link daemon commented on JENKINS-9009: --- Code changed in jenkins User: Kohsuke Kawaguchi Path: core/src/main/java/hudson/matrix/LabelAxis.java core/src/main/resources/hudson/matrix/LabelAxis/config.jelly test/src/test/groovy/hudson/matrix/MatrixProjectTest.groovy http://jenkins-ci.org/commit/matrix-project-plugin/eb607367cdf55bd9612b51f799e89845d15c8791 Log: [FIXED JENKINS-9009] Fixed a bug in handling ' and in matrix build label axis Originally-Committed-As: f46e44bbafb6de5c1757f63b8e3447a4743686ec Slave name with a quote breaks matrix build label axis -- Key: JENKINS-9009 URL: https://issues.jenkins-ci.org/browse/JENKINS-9009 Project: Jenkins Issue Type: Bug Components: matrix Environment: Linux, Tomcat, IE/FF/Chrome Reporter: dmeibusch Priority: Minor If a slave has a name with a single quote ('), the label axis option for a matrix build fails to render (blank panel). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-8848) custom workspace not available for maven or ivy projects
[ https://issues.jenkins-ci.org/browse/JENKINS-8848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163290#comment-163290 ] SCM/JIRA link daemon commented on JENKINS-8848: --- Code changed in jenkins User: Christoph Kutzinski Path: core/src/main/java/hudson/matrix/MatrixBuild.java core/src/main/java/hudson/matrix/MatrixProject.java http://jenkins-ci.org/commit/matrix-project-plugin/3a193ec6caa371ee2c4b56d5130364437ca87784 Log: [JENKINS-8848] allow custom workspaces for maven jobs Originally-Committed-As: e65f893b1bc0608ef57095c71eb0517c5353bda1 custom workspace not available for maven or ivy projects Key: JENKINS-8848 URL: https://issues.jenkins-ci.org/browse/JENKINS-8848 Project: Jenkins Issue Type: Bug Components: core, ivy Affects Versions: current Environment: Jenkins: 1.398 Server/Slave: Centos 5.5 Reporter: Peter Kline Assignee: kutzi We cannot use a custom workspace for our Ivy or Maven projects but it is available for the freestyle or matrix jobs. As we are rolling out multitarget parallel builds we would like to be able to share the workspace. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9293) CopyArtifacts plugin does not resolve axis of multi-config build from parameter
[ https://issues.jenkins-ci.org/browse/JENKINS-9293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163289#comment-163289 ] SCM/JIRA link daemon commented on JENKINS-9293: --- Code changed in jenkins User: alanharder Path: test/src/test/java/hudson/matrix/MatrixTest.java http://jenkins-ci.org/commit/matrix-project-plugin/cbc8e8215633d7d31878bba0b2dc8aa0466329ae Log: [JENKINS-9293] Add test that project-level permissions of a matrix project apply to child configurations as well. Originally-Committed-As: 2c767feea175aa2b7113216f10d0f972671a0e92 CopyArtifacts plugin does not resolve axis of multi-config build from parameter --- Key: JENKINS-9293 URL: https://issues.jenkins-ci.org/browse/JENKINS-9293 Project: Jenkins Issue Type: Bug Components: copyartifact Environment: Linux with different linux slaves Reporter: Johannes Wienke Assignee: Alan Harder The copy artifacts plugin seems to have a problem with selecting a single configuration from a multi-configuration build. I got two multi-config jobs which both use the nodes (label) as their only axis. Both jobs are built on the same set of nodes. For the downstream project I want to copy only the artifacts of the upstream project from the same node (because it is C++ and nodes are not compatible). So what I tried is this syntax to select the desired artifacts from the upstream project (called RSC-multi): RSC-multi/label=$label where $label is the axis. I've already checked that this variable is correct. Nevertheless, I i build this plugin, the copy step fails with this message: Unable to find project for artifact copy: RSC-multi/label=master (e.g. for the master node) It seems that the plugin does not recognize that this is a selection of one axis. If I remove $label from the expression and instead use a hard-coded selection of one axis like: RSC-multi/label=master then copying works correctly and only the artifacts from the master node are copied. So it seems that the selection of a single axis based on a parameter is broken. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9182) Performance: Specify image sizes for faster page loading
[ https://issues.jenkins-ci.org/browse/JENKINS-9182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163287#comment-163287 ] SCM/JIRA link daemon commented on JENKINS-9182: --- Code changed in jenkins User: Jesse Farinacci Path: core/src/main/resources/hudson/matrix/MatrixBuild/ajaxMatrix.jelly core/src/main/resources/hudson/matrix/MatrixProject/ajaxMatrix.jelly http://jenkins-ci.org/commit/matrix-project-plugin/e76d6f6dd9ed6404378edf1ac3b29d9c83b1eb0c Log: [FIXED JENKINS-9182] Performance: Specify image sizes for faster page loading Originally-Committed-As: 231c1c174675c6fa36036440a3e4b4a88d7471dc Performance: Specify image sizes for faster page loading Key: JENKINS-9182 URL: https://issues.jenkins-ci.org/browse/JENKINS-9182 Project: Jenkins Issue Type: Improvement Components: core Affects Versions: current Reporter: jieryn Assignee: jieryn Priority: Minor Please specify image dimensions for all image resources. Some images just need the sizes specified, others need to introspect the cookie setting for the image size. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9248) Please provide API to get matrixProject configuration information
[ https://issues.jenkins-ci.org/browse/JENKINS-9248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163292#comment-163292 ] SCM/JIRA link daemon commented on JENKINS-9248: --- Code changed in jenkins User: alanharder Path: core/src/main/java/hudson/matrix/MatrixBuild.java http://jenkins-ci.org/commit/matrix-project-plugin/a8e4487baa946cabed1976513c760b185f7cef36 Log: [FIXED JENKINS-9248] Add configuration info in remote API for matrix builds Originally-Committed-As: d869df004b478533dc3a839d4c82451dfc32f87a Please provide API to get matrixProject configuration information - Key: JENKINS-9248 URL: https://issues.jenkins-ci.org/browse/JENKINS-9248 Project: Jenkins Issue Type: Bug Components: matrix Environment: Jenkins-1.404 Reporter: kevincai Assignee: Alan Harder There is no API to provide the information that what are the axes configured for a matrixProject. Also no API to know what combination of configuration triggered for a certain build of matrixProject. Hence for these matrixProject, its downstream project can't be accessible with API unless you know exactly the axes it configured. This is a big limitation for automatic scripting in matrixProjects environment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9248) Please provide API to get matrixProject configuration information
[ https://issues.jenkins-ci.org/browse/JENKINS-9248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163291#comment-163291 ] SCM/JIRA link daemon commented on JENKINS-9248: --- Code changed in jenkins User: alanharder Path: core/src/main/java/hudson/matrix/MatrixProject.java test/src/test/java/hudson/matrix/MatrixTest.java http://jenkins-ci.org/commit/matrix-project-plugin/6fbf75ad1058b8bb3d545643ff5fd04ab9113256 Log: [JENKINS-9248] Add active configurations in remote API for matrix projects. Originally-Committed-As: be673713e4529467d413410c6a4d25786bd3cf9d Please provide API to get matrixProject configuration information - Key: JENKINS-9248 URL: https://issues.jenkins-ci.org/browse/JENKINS-9248 Project: Jenkins Issue Type: Bug Components: matrix Environment: Jenkins-1.404 Reporter: kevincai Assignee: Alan Harder There is no API to provide the information that what are the axes configured for a matrixProject. Also no API to know what combination of configuration triggered for a certain build of matrixProject. Hence for these matrixProject, its downstream project can't be accessible with API unless you know exactly the axes it configured. This is a big limitation for automatic scripting in matrixProjects environment. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-1613) Ability to build on configurable subset of matrix configurations
[ https://issues.jenkins-ci.org/browse/JENKINS-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163294#comment-163294 ] SCM/JIRA link daemon commented on JENKINS-1613: --- Code changed in jenkins User: Christian Wolfgang Path: core/src/main/java/hudson/matrix/MatrixBuild.java core/src/main/java/hudson/matrix/listeners/MatrixBuildListener.java http://jenkins-ci.org/commit/matrix-project-plugin/1b135d4cbc08da6959faf63842023962276675c8 Log: More on JENKINS-1613 Originally-Committed-As: f10b5eb4cd2d1d1fd68f0c469f7a9a78e45c68a4 Ability to build on configurable subset of matrix configurations Key: JENKINS-1613 URL: https://issues.jenkins-ci.org/browse/JENKINS-1613 Project: Jenkins Issue Type: New Feature Components: matrix Affects Versions: current Environment: Platform: All, OS: All Reporter: jazzjack Assignee: Christian Wolfgang It is useful sometimes to perform build on predefined number of slave builders assigned to multi-configuration job. For example, if some OS builds failed, and we wish to re-build only them after code fixed -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-3969) Status ball images should have transparent background
[ https://issues.jenkins-ci.org/browse/JENKINS-3969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163293#comment-163293 ] SCM/JIRA link daemon commented on JENKINS-3969: --- Code changed in jenkins User: Ulli Hafner Path: core/src/main/resources/hudson/matrix/MatrixBuild/ajaxMatrix.jelly core/src/main/resources/hudson/matrix/MatrixProject/ajaxMatrix.jelly http://jenkins-ci.org/commit/matrix-project-plugin/a86521e2a8bdf478e96ad038aeee60adca9fb0d9 Log: [FIXED JENKINS-3969] Replaced all gif images with corresponding png images. Originally-Committed-As: a4ba7bd268422e4ca7249e137b9dc0b6a20a84c0 Status ball images should have transparent background - Key: JENKINS-3969 URL: https://issues.jenkins-ci.org/browse/JENKINS-3969 Project: Jenkins Issue Type: Bug Components: gui Affects Versions: current Environment: Platform: All, OS: All Reporter: cristalp Assignee: Ulli Hafner Priority: Trivial Attachments: screenshot.png, screenshot2.png, wrong_status_ball.png I use the Emotional Hudson plugin, which shows the image of Hudson as a background of the build history. However, the status balls don't have a transparent background, which makes the whole thing look a bit ugly. Just cosmetics... :-) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9203) timer expires, and build is halted, but build is not marked as failed
[ https://issues.jenkins-ci.org/browse/JENKINS-9203?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163295#comment-163295 ] SCM/JIRA link daemon commented on JENKINS-9203: --- Code changed in jenkins User: Kohsuke Kawaguchi Path: core/src/main/java/hudson/matrix/MatrixBuild.java http://jenkins-ci.org/commit/matrix-project-plugin/7cab552d387727d1af3e5fa277ea4503bdc6242e Log: [FIXED JENKINS-9203] in light of 9c965617b3b385ef65eaf50860865c05a114a01d, I think the proper fix is to define a mechanism to abort with status. Originally-Committed-As: a3354b12cfc5f554487b59f35e5a0bdbce8861a6 timer expires, and build is halted, but build is not marked as failed - Key: JENKINS-9203 URL: https://issues.jenkins-ci.org/browse/JENKINS-9203 Project: Jenkins Issue Type: Bug Components: build-timeout Affects Versions: current Environment: Debian Lenny, Jenkins ver. 1.404 and build-timeout ver. 1.7 Reporter: Eric Engstrom Assignee: Kohsuke Kawaguchi Priority: Critical I just installed the build-timeout plugin and it's mostly working, but even with the Fail the build setting checked, my builds are still being marked as aborted: For example, here is the tail of the console output: {{ [...] Build timed out (after 3 minutes). Marking the build as failed. Terminated +++ vncserver -kill beast:3 -clean Killing Xtightvnc process ID 12328 +++ exit Finished: ABORTED }} Note that it says it will fail the build, but then it is aborted and the status of the build is set to aborted, not failed. Bonus pain: Of course no email goes out. This is with Jenkins ver. 1.404 and build-timeout ver. 1.7. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10108) Files uploaded via Fileparameter is not available in matrix jobs and throws NPE
[ https://issues.jenkins-ci.org/browse/JENKINS-10108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163297#comment-163297 ] SCM/JIRA link daemon commented on JENKINS-10108: Code changed in jenkins User: Kohsuke Kawaguchi Path: test/src/test/groovy/hudson/matrix/MatrixProjectTest.groovy http://jenkins-ci.org/commit/matrix-project-plugin/c9902c7b8254f1cac88bda55323f122c101ca696 Log: [FIXED JENKINS-10108] File parameter didn't work correctly with matrix projects. Originally-Committed-As: 47bc6d38c72f31babf2d453e87ccdf4c40f1f2a5 Files uploaded via Fileparameter is not available in matrix jobs and throws NPE --- Key: JENKINS-10108 URL: https://issues.jenkins-ci.org/browse/JENKINS-10108 Project: Jenkins Issue Type: Bug Components: matrix Affects Versions: current Environment: LINUX Reporter: ragesh_nair Have a mtrix job with more than one Fileparameters and upload 2 files on run time. The job thows NPE when you try to access the file uploaded. With one fileparameter it works but from 2 it fails. FATAL: null java.lang.NullPointerException at hudson.model.FileParameterValue$1.setUp(FileParameterValue.java:105) at hudson.model.Build$RunnerImpl.doRun(Build.java:133) at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:423) at hudson.model.Run.run(Run.java:1362) at hudson.matrix.MatrixRun.run(MatrixRun.java:137) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:145) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-4959) Block up-/downstream Projects of matrix projects
[ https://issues.jenkins-ci.org/browse/JENKINS-4959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163296#comment-163296 ] SCM/JIRA link daemon commented on JENKINS-4959: --- Code changed in jenkins User: cjo9900 Path: core/src/main/resources/hudson/matrix/MatrixProject/configure-entries.jelly http://jenkins-ci.org/commit/matrix-project-plugin/afdeb3440c7c9e06e58d2825fd8292cfd8deb024 Log: [FIXED JENKINS-4959] Add Downstream blocking for matrix projects. Originally-Committed-As: 591cbfd113cae53dd19c7c07119e97172fce6310 Block up-/downstream Projects of matrix projects Key: JENKINS-4959 URL: https://issues.jenkins-ci.org/browse/JENKINS-4959 Project: Jenkins Issue Type: Improvement Components: matrix Affects Versions: current Environment: Platform: All, OS: All Reporter: wohauser As implemented according to issue #1938 for maven builds, it should be possible to block up-/downstream project in matrix builds too. As a description, my problem: We have matrix projects a b c and d. They build a dependency chain a-b-c-d. At the time, if the projects changes the builds will start parallel and b,c and d don't have the proper results of the upstream projects and fail. If a is ready, b is scheduled and so on, the builds all are started again. On the other side, if d is running and a changes a have to wait until d (or b or c) is ready. At the time it will be started in parallel and probably the other projects fail while loosing its dependencies. Proposal: Matrix builds should have a flag to be able to block the execution of a project if an other project in the up-/downstream chain is running. If the blocking project has finished, the Queue should be reordered according to the up-/downstream chain and the projects should be build according to its dependencies. (already queued projects should wait until they are triggered from upstream project, or deleted from queue as they are started by the upstream project again) The parallel build of the axes should not be blocked. BTW, this is NOT a duplicate of issue #1938, because matrix projects don't support the blocking, like maven projects do, in using hudson version 1.335 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10197) Matrix jobs default to locked (and are difficult to delete)
[ https://issues.jenkins-ci.org/browse/JENKINS-10197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SCM/JIRA link daemon resolved JENKINS-10197. Resolution: Fixed Matrix jobs default to locked (and are difficult to delete) - Key: JENKINS-10197 URL: https://issues.jenkins-ci.org/browse/JENKINS-10197 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: 1.418, 1.434 Reporter: Tom Rini Assignee: abayer Priority: Critical With a matrix job now when it completes it defaults to being a keep forever type build. Only by deleting the current job can a previous job be deleted, in some cases. {noformat} (09:36:12 AM) Tartarus: kohsuke: With matrix jobs and 1.418 I'm seeing all of my jobs default to being locked, didn't see this with 1.409, any ideas? (09:36:32 AM) kohsuke: probably related to the partial rebuild support. Any ticket for this? (09:36:54 AM) Tartarus: Hadn't filed one yet (09:37:18 AM) kohsuke: Would you please? I don't think I can get it right now, but I don't want to forget {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11013) NOT_BUILT other build status are reported inconsistently
[ https://issues.jenkins-ci.org/browse/JENKINS-11013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163301#comment-163301 ] SCM/JIRA link daemon commented on JENKINS-11013: Code changed in jenkins User: Richard Mortimer Path: core/src/main/java/hudson/matrix/MatrixBuild.java core/src/main/resources/hudson/matrix/Messages.properties http://jenkins-ci.org/commit/matrix-project-plugin/2ecdf87e4e4820d7571eca36ec1d54b0f5c60782 Log: JENKINS-11013 NOT_BUILT other build status are reported inconsistently The parent matrix build console output does not record the build status for each job. That is useful to get a quick feel for the status of each job and the order of execution/completion. Originally-Committed-As: fd9d680c7451457dbd26b32e52aef7bc0bd37047 NOT_BUILT other build status are reported inconsistently -- Key: JENKINS-11013 URL: https://issues.jenkins-ci.org/browse/JENKINS-11013 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Jenkins 1.431 Ubuntu 1104 on x86 Reporter: Richard Mortimer Assignee: Richard Mortimer Priority: Minor If a build terminates with a NOT_BUILT status it is not reported correctly in a number of places: * The tooltip for the grey ball is Pending when it should be Not built. * The rss/atom build result feeds report status as ? * Matrix build tooltip reports a pending/queued build as skipped * The parent matrix build console output does not record the build status for each job. That is useful to get a quick feel for the status of each job and order of execution/completion. * NOT_BUILT can be returned as a previous build result when calculating unstable/back to normal build notifications -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10251) Configurations in a multi-configuration project (aka matrix project) are shown in a ugly, un-styled HTML table
[ https://issues.jenkins-ci.org/browse/JENKINS-10251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163302#comment-163302 ] SCM/JIRA link daemon commented on JENKINS-10251: Code changed in jenkins User: Costin Caraivan Path: core/src/main/resources/lib/hudson/project/matrix.jelly http://jenkins-ci.org/commit/matrix-project-plugin/770c9014b988779bf6025e8bb5b5ccbd30e905b5 Log: [JENKINS-10251] Styling the matrix configuration table to look more like Jenkins tables instead of the default HTML table look. Also moving the Configuration Matrix title as a part of the table, to gain some space. Originally-Committed-As: aba1616465e4a86ec7b7c0970a158d2229a2b037 Configurations in a multi-configuration project (aka matrix project) are shown in a ugly, un-styled HTML table -- Key: JENKINS-10251 URL: https://issues.jenkins-ci.org/browse/JENKINS-10251 Project: Jenkins Issue Type: Improvement Components: core Environment: Any Reporter: Costin Caraivan Priority: Minor Attachments: configuration-table.png When you make a matrix project with more than 1 axis, the configurations are arranged in a table. Unfortunately this table has the default HTML double borders, which are ugly, and look like something from the 90s. Jenkins already has a nice style for all the tables, like those from the job view. This style should be applied to the configurations table too. See the attached image for details. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10864) Matrix project page does not show test result information, though aggregate test result information does exist.
[ https://issues.jenkins-ci.org/browse/JENKINS-10864?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163299#comment-163299 ] SCM/JIRA link daemon commented on JENKINS-10864: Code changed in jenkins User: Andrew Bayer Path: core/src/main/resources/hudson/matrix/MatrixProject/index.jelly http://jenkins-ci.org/commit/matrix-project-plugin/ff8bac6950c4598cd2419c01c27c1cddc5e55428 Log: [FIXES JENKINS-10864] Adding Latest Test Results link to matrix project pages. Originally-Committed-As: a4d23231dd58fee47adc1a781ed63abb415214a1 Matrix project page does not show test result information, though aggregate test result information does exist. --- Key: JENKINS-10864 URL: https://issues.jenkins-ci.org/browse/JENKINS-10864 Project: Jenkins Issue Type: Bug Components: matrix Reporter: abayer Assignee: abayer If you go to a non-matrix job, it'll show the latest test results count and link, as well as latest aggregated test results count/link if that job is configured to do test result aggregation. Matrix jobs do not show this on the project page, but they should. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12199) In the Job configuration page, if the job doesn't have a display name, do not display the project name
[ https://issues.jenkins-ci.org/browse/JENKINS-12199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163304#comment-163304 ] SCM/JIRA link daemon commented on JENKINS-12199: Code changed in jenkins User: Albert So Path: core/src/main/resources/hudson/matrix/MatrixProject/configure-entries.jelly http://jenkins-ci.org/commit/matrix-project-plugin/27c98444a062fbd91fe176dcf1a87537e52e375a Log: [JENKINS-12199] Fixed bug where job configuration shows a displayname even though the job doesn't have a display name Originally-Committed-As: d8c12c026474dfa54ef3610f1d69feb50029692a In the Job configuration page, if the job doesn't have a display name, do not display the project name -- Key: JENKINS-12199 URL: https://issues.jenkins-ci.org/browse/JENKINS-12199 Project: Jenkins Issue Type: Bug Components: gui Reporter: Albert So Assignee: Albert So Once the display name changes have been merged in (see https://issues.jenkins-ci.org/browse/JENKINS-11762), one issue that popped up is that the project name is populated into the display name field if there is not display name set. This causes the project name to be set into the display name if you ever edit the configuration of a job. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13387) Convert Delete this build buttons into links in the sidepanel
[ https://issues.jenkins-ci.org/browse/JENKINS-13387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163305#comment-163305 ] SCM/JIRA link daemon commented on JENKINS-13387: Code changed in jenkins User: Fred G Path: core/src/main/resources/hudson/matrix/MatrixBuild/confirmDeleteAll_de.properties core/src/main/resources/hudson/matrix/MatrixBuild/delete.jelly core/src/main/resources/hudson/matrix/MatrixBuild/delete_de.properties core/src/main/resources/hudson/matrix/MatrixBuild/delete_ja.properties http://jenkins-ci.org/commit/matrix-project-plugin/c5149bfdd9c8bb643e1ea5ab4bdc59da72a509c6 Log: [FIXED JENKINS-13387] Converted Delete this build buttons into links in the sidepanel, added German translations for Delete Build links in Matrix Builds Originally-Committed-As: be88e0120fef6d5837ef9adf9b7803cbdde88b30 Convert Delete this build buttons into links in the sidepanel --- Key: JENKINS-13387 URL: https://issues.jenkins-ci.org/browse/JENKINS-13387 Project: Jenkins Issue Type: Improvement Components: gui, ui-changes Reporter: Fred G Assignee: Fred G Labels: gui Attachments: DeleteBuildButtons_MatrixBuild.png, DeleteBuildButtons_MatrixConfig.png, DeleteBuildLinks_MatrixBuild.png, DeleteBuildLinks_MatrixConfig.png The Delete this build buttons on build pages and also the Delete this build and all configurations of this build buttons on matrix build pages should be converted to links in the sidepanel of the respective pages (see Screenshots). This simplifies the user experience of deleting an object (see the Delete Project link in the sidepanel of project pages). Having the links in the sidepanel also makes them accessible through the newly added context menus that came with the breadcrumbs. Recent discussion about this topic: https://github.com/jenkinsci/jenkins/pull/403 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13387) Convert Delete this build buttons into links in the sidepanel
[ https://issues.jenkins-ci.org/browse/JENKINS-13387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163306#comment-163306 ] SCM/JIRA link daemon commented on JENKINS-13387: Code changed in jenkins User: Andrew Bayer Path: core/src/main/resources/hudson/matrix/MatrixBuild/confirmDeleteAll_de.properties core/src/main/resources/hudson/matrix/MatrixBuild/delete.jelly core/src/main/resources/hudson/matrix/MatrixBuild/delete_de.properties core/src/main/resources/hudson/matrix/MatrixBuild/delete_ja.properties http://jenkins-ci.org/commit/matrix-project-plugin/40b5d335cb705b8b23ffced089c44b792db5fb63 Log: Merge pull request #431 from fredg02/convertLinks [FIXED JENKINS-13387] Converted Delete this build buttons into links in the sidepanel Originally-Committed-As: 37fbcf4da2926f95098044f3abf5fff7707a806c Convert Delete this build buttons into links in the sidepanel --- Key: JENKINS-13387 URL: https://issues.jenkins-ci.org/browse/JENKINS-13387 Project: Jenkins Issue Type: Improvement Components: gui, ui-changes Reporter: Fred G Assignee: Fred G Labels: gui Attachments: DeleteBuildButtons_MatrixBuild.png, DeleteBuildButtons_MatrixConfig.png, DeleteBuildLinks_MatrixBuild.png, DeleteBuildLinks_MatrixConfig.png The Delete this build buttons on build pages and also the Delete this build and all configurations of this build buttons on matrix build pages should be converted to links in the sidepanel of the respective pages (see Screenshots). This simplifies the user experience of deleting an object (see the Delete Project link in the sidepanel of project pages). Having the links in the sidepanel also makes them accessible through the newly added context menus that came with the breadcrumbs. Recent discussion about this topic: https://github.com/jenkinsci/jenkins/pull/403 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-11013) NOT_BUILT other build status are reported inconsistently
[ https://issues.jenkins-ci.org/browse/JENKINS-11013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163300#comment-163300 ] SCM/JIRA link daemon commented on JENKINS-11013: Code changed in jenkins User: Richard Mortimer Path: core/src/main/resources/hudson/matrix/MatrixBuild/ajaxMatrix.jelly http://jenkins-ci.org/commit/matrix-project-plugin/560968ddfd12403b71ab435f59057270f93d1f56 Log: JENKINS-11013 NOT_BUILT other build status are reported inconsistently Matrix build tooltip reports a pending/queued build as skipped Originally-Committed-As: c444b42b1478be68b7f025772ed5a109f4107bf0 NOT_BUILT other build status are reported inconsistently -- Key: JENKINS-11013 URL: https://issues.jenkins-ci.org/browse/JENKINS-11013 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Jenkins 1.431 Ubuntu 1104 on x86 Reporter: Richard Mortimer Assignee: Richard Mortimer Priority: Minor If a build terminates with a NOT_BUILT status it is not reported correctly in a number of places: * The tooltip for the grey ball is Pending when it should be Not built. * The rss/atom build result feeds report status as ? * Matrix build tooltip reports a pending/queued build as skipped * The parent matrix build console output does not record the build status for each job. That is useful to get a quick feel for the status of each job and order of execution/completion. * NOT_BUILT can be returned as a previous build result when calculating unstable/back to normal build notifications -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13835) upgrading Subversion Plugin to 1.40 totally ruined our CI server
[ https://issues.jenkins-ci.org/browse/JENKINS-13835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163307#comment-163307 ] aristedes commented on JENKINS-13835: - I can report a very similar issue. The Subversion 1.7.4 server. 1.40 svn jenkins plugin. Pre-existing 1.6 workspace, and Jenkins set to use a 1.7 checkout format. The problem goes away if you choose 1.6 as the workspace format. {code} ERROR: Failed to update https://acme.com/ish/angel/trunk org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT /ish/!svn/vcc/default failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:304) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:289) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:277) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:696) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:328) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1289) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:837) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:557) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:414) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:324) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:315) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:295) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:391) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:136) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2154) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:287) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) Caused by: svn: E175002: REPORT /ish/!svn/vcc/default failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 33 more {code} Looks like it tries to upgrade the workspace and fails. upgrading Subversion Plugin to 1.40 totally ruined our CI server Key: JENKINS-13835 URL: https://issues.jenkins-ci.org/browse/JENKINS-13835 Project: Jenkins Issue Type: Bug Components: subversion Environment: Jenkins ver. 1.460; Subversion Plugin ver. 1.40, 1.39; Windows Server 2003 R2 x64 SP2; Subversion server ver. 1.6.16. Reporter: pancake Labels: plugin, subversion, windows Updating Subversion Plugin to 1.40 caused multiple bugs. Rolling back to 1.39 resulted to {color:red}complete inability to perform a checkout. CI server is totally unusable now.{color} *Issue #1* After updating to Subversion Plugin to 1.40 (from 1.39) this exception started occurring _sometimes_ (various salves, various jobs): {quote} Checking out a fresh workspace because there's no workspace at C:\_JenkinsCI\workspace\XXX Cleaning local Directory .
[JIRA] (JENKINS-13836) Stable release issues|Loading All Build History Fails in stable release 1.447.1
[ https://issues.jenkins-ci.org/browse/JENKINS-13836?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=163308#comment-163308 ] Yusuf Burmawala commented on JENKINS-13836: --- I am facing similar issue while running Jenkins v1.447.1 under tomcat6 and have re-opened the following ticket, https://issues.jenkins-ci.org/browse/JENKINS-5450 Note:- Standalone installation of Jenkins doesn't have this issue. Also noticed that 1.465 doesn't have this problem but I want to use 1.447.1 as it is an LTS release. Stable release issues|Loading All Build History Fails in stable release 1.447.1 --- Key: JENKINS-13836 URL: https://issues.jenkins-ci.org/browse/JENKINS-13836 Project: Jenkins Issue Type: Bug Components: core Affects Versions: current Environment: Prodution Reporter: Arvind Ramalingam Priority: Blocker Hi I have upgraded my Production Jenkins to 1.447.1 and I am not able to see my build history.When I try to view more of my build history I get the below error.Please let me know which stable release should i revert back to and I was at 1.409 and everything was fine. HTTP Status 404 - type Status report message description The requested resource () is not available. Apache Tomcat/6.0.26 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13942) Cannot display the view for Readonly user
Sam He created JENKINS-13942: Summary: Cannot display the view for Readonly user Key: JENKINS-13942 URL: https://issues.jenkins-ci.org/browse/JENKINS-13942 Project: Jenkins Issue Type: Bug Components: nested-view, view-job-filters Reporter: Sam He Assignee: Alan Harder I created some views in the Jeninks instances : 1. nested-view 2. general view with User Permissions for Job filter 3. general view with Logged-in user Relevance filter Readonly user (Administrator:Read) cannot display this views. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jenkins-ci.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira