[JIRA] (JENKINS-15875) Cannot change "Usage" setting of master jenkins
c089 created JENKINS-15875 Cannot change "Usage" setting of master jenkins Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: master-slave Created: 20/Nov/12 8:08 AM Description: Steps to reproduce: go to "manage nodes" screen click configure icon next to master node set usage setting from "utilize as much as possible" to "leave this machine for tied jobs only" click save go back to the configure page Expected: Usage setting was set to "leave for tied jobs" Actual: Usage setting was set back to "utilize as much as possible" Project: Jenkins Priority: Major Reporter: c089 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15760) java.lang.NullPointerException when starting job
Gil Shinar resolved JENKINS-15760 as Fixed java.lang.NullPointerException when starting job Version 1.6 has an additional XML element named "configs" that version 1.5 did not have. An exception error has occurred because the configs object was null. Change By: Gil Shinar (20/Nov/12 8:33 AM) Status: Open Resolved Assignee: Gil Shinar Fix Version/s: current Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15872) Running 'rlog' after 'cvs up -r TAG' superfluous & giving incorrect change log for the workspace
Michael Clarke commented on JENKINS-15872 Running 'rlog' after 'cvs up -r TAG' superfluous & giving incorrect change log for the workspace Could you attach the RLOG output for this commit? I'll then include it in a test case. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15821) Cannot install prqa-plugin
XYZ commented on JENKINS-15821 Cannot install prqa-plugin Hello Mads & Jason, after installation of these tools the plugin works fine. Regards, Frank This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15876) how to sync code only if a changelist is pending
alok kumar created JENKINS-15876 how to sync code only if a changelist is pending Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: perforce Created: 20/Nov/12 10:43 AM Description: How can I stop perforce plugin from not syncing the code when there is no changelist pending for the view set up in the job? Poll SCM does trigger a build only when a pending change list is present, but, how do I accomplish the case of building the job with the same code until and unless a chnagelist has been submitted. This is urgent as its blocking our release. Due Date: 21/Nov/12 12:00 AM Fix Versions: current Project: Jenkins Priority: Blocker Reporter: alok kumar This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15877) CLONE - E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request
amit vyas created JENKINS-15877 CLONE - E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request Issue Type: Bug Assignee: Unassigned Components: subversion Created: 20/Nov/12 10:50 AM Description: Updating Subversion Plugin to 1.40 caused multiple bugs. Rolling back to 1.39 resulted to complete inability to perform a checkout. CI server is totally unusable now. Issue #1 After updating to Subversion Plugin to 1.40 (from 1.39) this exception started occurring sometimes (various salves, various jobs): Checking out a fresh workspace because there's no workspace at C:_JenkinsCI\workspace\XXX Cleaning local Directory . Checking out http://oursvnserver/svn/svnLatest/.../XXX A ... ERROR: Failed to check out http://oursvnserver/svn/svnLatest/.../XXX org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT /svn/svnLatest/!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.wc2.ng.SvnNgAbstractUpdate.updateInternal(SvnNgAbstractUpdate.java:216) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:100) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:756) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:14) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgCheckout.run(SvnNgCheckout.java:9) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgOperationRunner.run(SvnNgOperationRunner.java:20) 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.doCheckout(SVNUpdateClient.java:781) at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:85) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:152) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:121) 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:662) Caused by: svn: E175002: REPORT /svn/svnLatest/!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) ... 35 more FATAL: null java.lang.NullPoin
[JIRA] (JENKINS-15237) Dependent Maven Jobs ignore version-number
Julien Carsique commented on JENKINS-15237 Dependent Maven Jobs ignore version-number Complementary info: not specific to Windows, nor Maven 3; reproduced on Linux, Maven 2.2.1, Jenkins 1.481 to 1.491 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15865) Jenkins build fails with fatal error for Maven 2 build of project with maven-failsafe-plugin
Thomas Kallenberg commented on JENKINS-15865 Jenkins build fails with fatal error for Maven 2 build of project with maven-failsafe-plugin We have exactly the same problem. Our every build fails with the same stacktrace at the end of the build: [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:247) at org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:137) at org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56) at hudson.maven.agent.ComponentConfiguratorFilter.configureComponent(ComponentConfiguratorFilter.java:49) at hudson.maven.agent.PluginManagerInterceptor$MojoIntercepter.configureComponent(PluginManagerInterceptor.java:146) at org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1357) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:724) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:468) at hudson.maven.agent.PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:182) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at hudson.maven.agent.Main.launch(Main.java:185) at hudson.maven.MavenBuilder.call(MavenBuilder.java:151) at hudson.maven.Maven2Builder.call(Maven2Builder.java:77) at hudson.maven.Maven2Builder.call(Maven2Builder.java:53) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) 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:662) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15237) Dependent Maven Jobs ignore version-number
Julien Carsique edited a comment on JENKINS-15237 Dependent Maven Jobs ignore version-number Great to see it fixed in JENKINS-15367, for 1.492 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15821) Cannot install prqa-plugin
Mads Nielsen commented on JENKINS-15821 Cannot install prqa-plugin Hey Frank, Good to hear, if you got a spare minute, we would really appreciate if you would write a short description on how you plan on using it HERE. Just edit the page with your story. Regards, Mads This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14204) jenkins-multijob-plugin - The MultiJob shouldn't consume an executor
Liya Katz resolved JENKINS-14204 as Not A Defect jenkins-multijob-plugin - The MultiJob shouldn't consume an executor Change By: Liya Katz (20/Nov/12 12:10 PM) Status: Open Resolved Resolution: Not A Defect This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15865) Jenkins build fails with fatal error for Maven 2 build of project with maven-failsafe-plugin
Andrew Jones updated JENKINS-15865 Jenkins build fails with fatal error for Maven 2 build of project with maven-failsafe-plugin Change By: Andrew Jones (20/Nov/12 12:09 PM) Environment: Linux 2.6.38-16-generic #67-Ubuntu SMP Thu Sep 6 17:58:38 UTC 2012 x86_64 x86_64 x86_64 GNU/LinuxUbuntu 11.04Maven 2.2.1 Jenkins 1.491 Description: Jenkins build fails with "[ERROR] FATAL ERROR" if you build a Maven 2 project that uses maven-failsafe-plugin.Steps to reproduce:1. Create a new job in Jenkins2. Specify Maven2/3 job3. Choose Git in source code management4. Specify https://github.com/ahjones/broken-failsafe-maven as the repo5. Choose Maven 2.2.1 as the Maven version.6. Save the build7. Click build.Expected behaviour:The build completesActual behaviour:The build doesn't complete. The relevant portion of the console output is:[ERROR] FATAL ERROR[INFO] [INFO] null[INFO] [INFO] Tracejava.lang.NullPointerException at org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:247) at org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:137) at org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56) at hudson.maven.agent.ComponentConfiguratorFilter.configureComponent(ComponentConfiguratorFilter.java:49) at hudson.maven.agent.PluginManagerInterceptor$MojoIntercepter.configureComponent(PluginManagerInterceptor.java:146) at org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1357) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:724) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:468) at hudson.maven.agent.PluginManagerInterceptor.executeMojo(PluginManagerInterceptor.java:182) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180) at org.apache.maven.lifecycle.LifecycleExecutorInterceptor.execute(LifecycleExecutorInterceptor.java:65) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138) at org.apache.maven.cli.MavenCli.main(MavenCli.java:362) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at hudson.maven.agent.Main.launch(Main.java:185) at hudson.maven.MavenBuilder.call(MavenBuilder.java:151) at hudson.maven.Maven2Builder.call(Maven2Builder.java:77) at hudson.maven.Maven2Builder.call(Maven2Builder.java:53) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurren
[JIRA] (JENKINS-14204) jenkins-multijob-plugin - The MultiJob shouldn't consume an executor
Liya Katz commented on JENKINS-14204 jenkins-multijob-plugin - The MultiJob shouldn't consume an executor MultiJob should consume an executer since it can have steps that are not MultiJob phases This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9467) jenkins-plugin-info macro assumes subversion when it can't find github
Titas Norkūnas commented on JENKINS-9467 jenkins-plugin-info macro assumes subversion when it can't find github If it is not github, it should just take the tag from POM and not try to guess what type of SCM it is... We are having a problem with this plugin that is hosted on Assembla: https://wiki.jenkins-ci.org/display/JENKINS/Assembla+Auth+Plugin This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-14481) [cppcheck] Quickly identify only the new errors
Jan Klass commented on JENKINS-14481 [cppcheck] Quickly identify only the new errors I don’t think an additional column is the way to go. Instead, as you suggested, a separate table should be used to show new errors (and another to show fixed errors). The overview integer indicating how many new errors there are should then link to that table/a separate result page with that table. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15821) Cannot install prqa-plugin
XYZ commented on JENKINS-15821 Cannot install prqa-plugin Hi Mads, would it be possisble that the user can edit the QAR output path in one of the next plugin releases? I nice feature would be also to call the plugin two times: I have here a mixed C/C++ project and I want to call QA-C and QA-CPP. What do you think about it? Regards, Frank This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15878) scripler explicit classpath
Andrei Pozolotin created JENKINS-15878 scripler explicit classpath Issue Type: Bug Assignee: domi Components: scriptler Created: 20/Nov/12 1:51 PM Description: Dominik: currently, "scriptler" uses either jenkins classloader or TCCL; https://github.com/jenkinsci/scriptler-plugin do you think it would be feasible for "scriptler" also to support explicit classpath? say, similar to how "dynamicparameter" plugin is doing this now: https://github.com/Seitenbau/sb-jenkins-dynamicparameter namely: https://github.com/Seitenbau/sb-jenkins-dynamicparameter/blob/master/src/main/java/com/seitenbau/jenkins/plugins/dynamicparameter/util/JenkinsUtils.java#L98 1) provide capability to define "jar folder" location on jenkins 2) replicate this folder to all jenkins slaves 3) add these folders to the GroovyShell classpath finally, since "dynamicparameter" depends on "scriptler", you could probably agree with authors of "dynamicparameter" to move this functionality into the "scriptler" and make it a shared feature for all groovy script plugins? thank you; Andrei. Project: Jenkins Priority: Major Reporter: Andrei Pozolotin This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15879) Tag this build does not work for 'partial checkouts'
Valentin Batz created JENKINS-15879 Tag this build does not work for 'partial checkouts' Issue Type: Bug Assignee: Unassigned Components: cvs Created: 20/Nov/12 1:52 PM Description: When checking out // as a module and trying to tag the build, this error message occurs: cvsnt rtag: cannot find module `' - ignored So all the single files that are checked out as modules don't get tagged. Environment: Jenkins 1.489 CVS plugin 2.7 Project: Jenkins Priority: Major Reporter: Valentin Batz This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15860) Mail body for two simultaneous mails get mixed
Slide-O-Mix commented on JENKINS-15860 Mail body for two simultaneous mails get mixed Can you also upload the emails (as HTML or txt files depending on your content type) so I can see the end result? Please remove any company details. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15878) scriptler explicit classpath
Andrei Pozolotin updated JENKINS-15878 scriptler explicit classpath Change By: Andrei Pozolotin (20/Nov/12 2:01 PM) Summary: scripler scriptler explicit classpath This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15880) Please add a configurable 'quiet'/'really quiet' (-q/-Q) switch for the CVS Plugin
Valentin Batz created JENKINS-15880 Please add a configurable 'quiet'/'really quiet' (-q/-Q) switch for the CVS Plugin Issue Type: New Feature Assignee: Unassigned Components: cvs Created: 20/Nov/12 2:03 PM Description: The CVS Plugin starting from 2.x generates too much output. This may affect the build time and the log sizes. Please add a configurable 'quiet' and 'really quiet' switch and enable at least 'quiet' by default. The old plugin did always set the 'quiet' switch by default. Project: Jenkins Priority: Minor Reporter: Valentin Batz This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15865) Jenkins build fails with fatal error for Maven 2 build of project with maven-failsafe-plugin
SCM/JIRA link daemon commented on JENKINS-15865 Jenkins build fails with fatal error for Maven 2 build of project with maven-failsafe-plugin Code changed in jenkins User: Olivier Lamy Path: changelog.html maven-plugin/src/main/java/hudson/maven/reporters/SurefireArchiver.java http://jenkins-ci.org/commit/jenkins/921d85f24973ace266686d47449fed1bc74130aa Log: Merge pull request #624 from Vlatombe/JENKINS-15865 JENKINS-15865 Jenkins build fails with fatal error for Maven 2 build Thanks Compare: https://github.com/jenkinsci/jenkins/compare/8167710202f7...921d85f24973 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15865) Jenkins build fails with fatal error for Maven 2 build of project with maven-failsafe-plugin
SCM/JIRA link daemon commented on JENKINS-15865 Jenkins build fails with fatal error for Maven 2 build of project with maven-failsafe-plugin Code changed in jenkins User: Vincent Latombe Path: changelog.html maven-plugin/src/main/java/hudson/maven/reporters/SurefireArchiver.java http://jenkins-ci.org/commit/jenkins/7fb1ad44d5aa26f2b0c6717c589b6d2be698224d Log: JENKINS-15865 Jenkins build fails with fatal error for Maven 2 build of project with maven-failsafe-plugin Do not inject testFailureIgnore to maven-failsafe-plugin:integration-test because it doesn't exist and causes an NPE with Maven2. Only insert it for maven-failsafe-plugin:verify. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15880) Please add a configurable 'quiet'/'really quiet' (-q/-Q) switch for the CVS Plugin
Valentin Batz updated JENKINS-15880 Please add a configurable 'quiet'/'really quiet' (-q/-Q) switch for the CVS Plugin Change By: Valentin Batz (20/Nov/12 2:10 PM) Issue Type: New Feature Improvement This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15881) svn revision check failed when checking out older revision after HEAD build
Daniel Kleinert created JENKINS-15881 svn revision check failed when checking out older revision after HEAD build Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: subversion Created: 20/Nov/12 2:19 PM Description: When the last build was HEAD revision and the new build is an older revision the revision check will fail. The problem arises in https://github.com/jenkinsci/subversion-plugin/blob/master/src/main/java/hudson/scm/SubversionChangeLogBuilder.java#L161 SVNRevision.create(prevRev+1) if prevRev == HEAD, prevRev+1 will be an invalid revision hudson.util.IOException2: revision check failed on https://XXX at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:170) at hudson.scm.SubversionChangeLogBuilder.run(SubversionChangeLogBuilder.java:112) at hudson.scm.SubversionSCM.calcChangeLog(SubversionSCM.java:564) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:713) at hudson.model.AbstractProject.checkout(AbstractProject.java:1308) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:676) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:581) at hudson.model.Run.execute(Run.java:1516) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: org.tmatesoft.svn.core.SVNException: svn: E160006: No such revision 37 svn: E175002: REPORT of '/XXX/!svn/bc/36': 500 Internal Server Error (https://XXX) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLocationsImpl(DAVRepository.java:1066) at org.tmatesoft.svn.core.io.SVNRepository.getLocations(SVNRepository.java:1088) at org.tmatesoft.svn.core.io.SVNRepository.getLocations(SVNRepository.java:1516) at org.tmatesoft.svn.core.internal.wc2.SvnRepositoryAccess.getLocations(SvnRepositoryAccess.java:178) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:44) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:160) at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteLog.run(SvnRemoteLog.java:35) 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.SVNLogClient.doLog(SVNLogClient.java:967) at org.tmatesoft.svn.core.wc.SVNLogClient.doLog(SVNLogClient.java:872) at hudson.scm.SubversionChangeLogBuilder.buildModule(SubversionChangeLogBuilder.java:158) ... 11 more Caused by: svn: E160006: No such revision 37 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) at org.tmatesoft.svn.core.internal.io.dav.handlers.DAVErrorHandler.endElement(DAVErrorHandler.java:72) at org.tmatesoft.svn.core.internal.io.dav.handlers.BasicDAVHandler.endElement(BasicDAVHandler.java:103) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:601) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1782) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2938) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:140) at
[JIRA] (JENKINS-15367) Jenkins kicks off the wrong downstream builds for Maven
Julien Carsique commented on JENKINS-15367 Jenkins kicks off the wrong downstream builds for Maven Successfully tested on 1.491 with a cherry-pick of 4043905580df5bf22cde0eaf3dec103abdc88017 I tried with https://github.com/nuxeo/nuxeo-common/ and https://github.com/nuxeo/nuxeo-runtime/ with their "master" and "5.6.0" branches. I couldn't try much more with https://github.com/vietj/chromattic and https://github.com/vietj/wikbook because of build issues but it seems fine on the POM parsing part. Before the fix, nuxeo-common master (version 5.7-SNAPSHOT) was triggering nuxeo-runtime master (version 5.7-SNAPSHOT) and 5.6.0 (version 5.6.0-HF04-SNAPSHOT), whereas nuxeo-common 5.6.0 was triggering nothing at all. Note I didn't try to reproduce the issue with chromattic and wikbook before the fix. However, even if the triggering is fixed, I still have an issue (I don't know if it's exactly the same issue): relationship between builds is sticked at builds earlier the fix if there was no build before the fix, then the relationship is empty I'm talking about jenkins/projectRelationship?lhs=nuxeo-common-5.6.0&rhs=nuxeo-runtime-5.6.0 and jenkins/projectRelationship?lhs=nuxeo-common-master&rhs=nuxeo-runtime-master Before 1.480, the relationship is right. Since 1.481 until 1.491, without the current fix, the relationship seems still right even if triggering is wrong (see comment-168178 on JENKINS-15237). With the current fix applied on 1.491, the relationship is no more updated (new builds are ignored). Of course, that new issue appears on the summary views: upstream/downstream information on jobs is right whereas upstream/downstream information on builds is simply missing. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-12610) java.io.IOException: Unable to delete - Deleting Project
daniel anggrianto commented on JENKINS-12610 java.io.IOException: Unable to delete - Deleting Project i am having this issue as well i dont have any unicode character on the build name. i am running version 1.491 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15880) Please add a configurable 'quiet'/'really quiet' (-q/-Q) switch for the CVS Plugin
Michael Clarke closed JENKINS-15880 as Duplicate Please add a configurable 'quiet'/'really quiet' (-q/-Q) switch for the CVS Plugin Change By: Michael Clarke (20/Nov/12 2:45 PM) Status: Open Closed Assignee: Michael Clarke Resolution: Duplicate This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-10551) Check the parameter from upstream job to trigger a release build
wernight commented on JENKINS-10551 Check the parameter from upstream job to trigger a release build To upgrade there is the Promote plugin which does actually pretty much everything described. However a release trigger would be most welcome. A configurable trigger like the normal job trigger. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15865) Jenkins build fails with fatal error for Maven 2 build of project with maven-failsafe-plugin
dogfood commented on JENKINS-15865 Jenkins build fails with fatal error for Maven 2 build of project with maven-failsafe-plugin Integrated in jenkins_main_trunk #2088 JENKINS-15865 Jenkins build fails with fatal error for Maven 2 build (Revision 7fb1ad44d5aa26f2b0c6717c589b6d2be698224d) Result = SUCCESS Vincent Latombe : 7fb1ad44d5aa26f2b0c6717c589b6d2be698224d Files : maven-plugin/src/main/java/hudson/maven/reporters/SurefireArchiver.java changelog.html This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15882) rebuild plugin should not store non-stored password parameter
Kiril Nesenko created JENKINS-15882 rebuild plugin should not store non-stored password parameter Issue Type: Bug Affects Versions: current Assignee: ragesh_nair Components: rebuild Created: 20/Nov/12 3:26 PM Description: I have a job with store non-stored password parameter. When trying to rebuild the job, password is stored. Expected results: The rebuild plugin should not keep passwords. When clicking on rebuild button, it should promt for password once again. Project: Jenkins Priority: Critical Reporter: Kiril Nesenko This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15878) scriptler explicit classpath
domi updated JENKINS-15878 scriptler explicit classpath Change By: domi (20/Nov/12 4:10 PM) Issue Type: Bug New Feature This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15858) Jenkinks UI blocking on some calls
Elmar Deppe commented on JENKINS-15858 Jenkinks UI blocking on some calls Got the same problem with 1.489 (running in a tomcat 6). Here is the relevant segment from the thread dump. Found one Java-level deadlock: = "Handling GET /jenkins//api/xml : http-8080-37": waiting to lock monitor 0x103b4a88 (object 0x000780a10130, a hudson.model.RunMap), which is held by "Handling GET /jenkins/ : http-8080-6" "Handling GET /jenkins/ : http-8080-6": waiting to lock monitor 0x11f37498 (object 0x0007871608c8, a hudson.maven.MavenBuild), which is held by "Executor #0 for master : executing DSODP_branch_DEV-1.3 #144" "Executor #0 for master : executing DSODP_branch_DEV-1.3 #144": waiting to lock monitor 0x103b4a88 (object 0x000780a10130, a hudson.model.RunMap), which is held by "Handling GET /jenkins/ : http-8080-6" Java stack information for the threads listed above: === "Handling GET /jenkins//api/xml : http-8080-37": at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:638) - waiting to lock <0x000780a10130> (a hudson.model.RunMap) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:621) at jenkins.model.lazy.AbstractLazyLoadRunMap.getById(AbstractLazyLoadRunMap.java:498) at jenkins.model.lazy.AbstractLazyLoadRunMap.search(AbstractLazyLoadRunMap.java:472) at hudson.model.AbstractProject.getNearestOldBuild(AbstractProject.java:1025) at hudson.maven.MavenModuleSetBuild.getModuleLastBuilds(MavenModuleSetBuild.java:434) at hudson.maven.MavenModuleSetBuild.getResult(MavenModuleSetBuild.java:189) at hudson.model.Job.getLastFailedBuild(Job.java:823) at sun.reflect.GeneratedMethodAccessor82.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.kohsuke.stapler.export.MethodProperty.getValue(MethodProperty.java:66) at org.kohsuke.stapler.export.Property.writeTo(Property.java:114) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:187) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:182) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:182) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:182) at org.kohsuke.stapler.export.Property.writeValue(Property.java:232) at org.kohsuke.stapler.export.Property.writeValue(Property.java:182) at org.kohsuke.stapler.export.Property.writeValue(Property.java:137) at org.kohsuke.stapler.export.Property.writeTo(Property.java:114) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:187) at org.kohsuke.stapler.export.Model.writeNestedObjectTo(Model.java:182) at org.kohsuke.stapler.export.Model.writeTo(Model.java:154) at hudson.model.Api.doXml(Api.java:103) at sun.reflect.GeneratedMethodAccessor391.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:573) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:658) 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:573) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:658) at org.kohsuke.stapler.Stapler.invoke(Stapler.java:487) at org.kohsuke.stapler.Stapler.service(Stapler.java:164) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206) at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:95) at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:87) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235) at org.apache.catalin
[JIRA] (JENKINS-15858) Jenkinks UI blocking on some calls / DEADLOCK
Elmar Deppe updated JENKINS-15858 Jenkinks UI blocking on some calls / DEADLOCK Change By: Elmar Deppe (20/Nov/12 4:27 PM) Summary: Jenkinks UI blocking on some calls / DEADLOCK This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-13617) 64-bit java.lang.OutOfMemoryError: PermGen space
Steve Roth commented on JENKINS-13617 64-bit java.lang.OutOfMemoryError: PermGen space me too, on 1.491 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15883) Allow to automatically trigger jobs when a project import the dependencyManagement of another
Arnaud Héritier created JENKINS-15883 Allow to automatically trigger jobs when a project import the dependencyManagement of another Issue Type: New Feature Assignee: olamy Components: maven Created: 20/Nov/12 6:00 PM Description: Let's take 2 maven projects A and B deploying their SNAPSHOTs with 2 jenkins jobs. If B imports the dependencyManagement of a pom from A (using the scope import), when A succeed we should be able to have an automatic triggering of B build (like for a classical dependency) Project: Jenkins Priority: Major Reporter: Arnaud Héritier This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
SSH connection from Jenkins to Tomcat server failing
Hi Team, I have a Jenkins job to restart Tomcat automatically configured. I have added a server-restart named job with the below config jenkins@qa-gse01:22 cd /opt/tomcat/app/apache-tomcat-6.0.26/bin ./catalina.sh stop -force cd /opt/tomcat/app/apache-tomcat-6.0.26/bin ./catalina.sh start I have added the pre-build step to make a cd to Tomcat bin directory & execute the stop script(catalina.sh) And the post-build step to make a cd to Tomcat bin directory & execute the start script(catalina.sh) After running the job, I see the below exception. Building in workspace /var/lib/jenkins/jobs/QA-server-restart/workspace [SSH] executing pre build script: cd /opt/tomcat/app/apache-tomcat-6.0.26/bin ./catalina.sh stop -force [SSH] Exception:Auth cancel com.jcraft.jsch.JSchException: Auth cancel at com.jcraft.jsch.Session.connect(Session.java:451) at com.jcraft.jsch.Session.connect(Session.java:150) at org.jvnet.hudson.plugins.SSHSite.createSession(SSHSite.java:118) at org.jvnet.hudson.plugins.SSHSite.executeCommand(SSHSite.java:128) at org.jvnet.hudson.plugins.SSHBuildWrapper.executePreBuildScript(SSHBuildWrapper.java:78) at org.jvnet.hudson.plugins.SSHBuildWrapper.setUp(SSHBuildWrapper.java:62) at hudson.model.Build$BuildExecution.doRun(Build.java:154) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499) at hudson.model.Run.execute(Run.java:1502) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Finished: FAILURE While I do a SSH directly from the Jenkins LINUX box to the Tomcat server(qa-gse01), I'm able to login but the job to do the same task is failing. Can you guys please help me on this, I'm stuck !! -- View this message in context: http://jenkins.361315.n4.nabble.com/SSH-connection-from-Jenkins-to-Tomcat-server-failing-tp4646747.html Sent from the Jenkins issues mailing list archive at Nabble.com.
[JIRA] (JENKINS-15876) how to sync code only if a changelist is pending
Rob Petti resolved JENKINS-15876 as Not A Defect how to sync code only if a changelist is pending Change By: Rob Petti (20/Nov/12 6:52 PM) Status: Open Resolved Resolution: Not A Defect This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15876) how to sync code only if a changelist is pending
Rob Petti commented on JENKINS-15876 how to sync code only if a changelist is pending You can't, but syncing when there aren't any changes is a very lightweight process, and only takes a second or two. It'll ask perforce to sync, realize there aren't any changes, then return immediately. I'm not sure this classifies as an issue, so I'm going to go ahead and close it. If you need to talk about it some more then feel free to send me an email (rob.petti at gmail.com). This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-7004) cause not working in parameterized projects
Adam Monsen commented on JENKINS-7004 cause not working in parameterized projects FYI, it appears cause must follow token in the query string or cause is discarded. For example: ?token=x&cause=y works, but ?cause=y&token=x discards cause. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15515) Provide environment variable for the last changeset that contributed to a projects build
SCM/JIRA link daemon resolved JENKINS-15515 as Fixed Provide environment variable for the last changeset that contributed to a projects build Change By: SCM/JIRA link daemon (20/Nov/12 7:37 PM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15515) Provide environment variable for the last changeset that contributed to a projects build
SCM/JIRA link daemon commented on JENKINS-15515 Provide environment variable for the last changeset that contributed to a projects build Code changed in jenkins User: Rob Petti Path: src/main/java/hudson/plugins/perforce/PerforceSCM.java http://jenkins-ci.org/commit/perforce-plugin/840c94ce920a7e43a89e21c409bb1a8d24ca6814 Log: [FIXED JENKINS-15515] prefer workspace changeset before depot changeset This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15862) perforce session ticket is not always parsed correctly
Rob Petti commented on JENKINS-15862 perforce session ticket is not always parsed correctly I don't know what coverity is, or how it's injecting itself in front of the p4 commands, but just taking the second line as you suggested should at least fix the ticket issue. I am concerned, however, since the other command parsing algorithms are just as naive because we assume that we'll only ever be interacting directly with perforce. If the other commands throw similar 'junk' output, you will probably still run into other issues further down the line. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15862) perforce session ticket is not always parsed correctly
SCM/JIRA link daemon commented on JENKINS-15862 perforce session ticket is not always parsed correctly Code changed in jenkins User: Rob Petti Path: src/main/java/com/tek42/perforce/parse/AbstractPerforceTemplate.java http://jenkins-ci.org/commit/perforce-plugin/707d9d2251eec668e0ac1ff816477589471e65c4 Log: [FIXED JENKINS-15862] take ticket from second line of 'p4 login' output This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15862) perforce session ticket is not always parsed correctly
SCM/JIRA link daemon resolved JENKINS-15862 as Fixed perforce session ticket is not always parsed correctly Change By: SCM/JIRA link daemon (20/Nov/12 7:48 PM) Status: Open Resolved Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15603) Cannot find changelist number for arbitrary job (api/xml should list it)
SCM/JIRA link daemon commented on JENKINS-15603 Cannot find changelist number for arbitrary job (api/xml should list it) Code changed in jenkins User: Rob Petti Path: src/main/java/hudson/plugins/perforce/PerforceTagAction.java http://jenkins-ci.org/commit/perforce-plugin/d04ccd57289423b0cd9f846775f1ed1bf1bf10a5 Log: JENKINS-15603 export changenumber from perforcetagaction This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15860) Mail body for two simultaneous mails get mixed
Xavier Nodet commented on JENKINS-15860 Mail body for two simultaneous mails get mixed Here's the result. Both mails had the same... I removed the console output. It was small, and thus completely included in the mail. --- BUILD FAILURE Project: check-unmerged-commits Project URL: https://my.jenkins.server/job/check-unmerged-commits/ Build URL: https://my.jenkins.server/job/check-unmerged-commits/15/ Date of build: Sat, 17 Nov 2012 22:01:16 -0800 Build duration: 0.24 sec Machine used: [the machine name] ([the agent's name]) CHANGE SET No changes PREVIOUS BUILDS Previous build (#14) was SUCCESS. CONSOLE OUTPUT Started by timer Building remotely [removed the whole output from the console] Full console log: https://my.jenkins.server/job/check-unmerged-commits/15/consoleFull Edit build description: https://my.jenkins.server/job/check-unmerged-commits/15/configure --- I hope this helps. Thanks. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15860) Mail body for two simultaneous mails get mixed
Slide-O-Mix commented on JENKINS-15860 Mail body for two simultaneous mails get mixed What exactly is mixed? From what I saw in the config.xml files, the same template is being used. So, what is being mixed? You'll have to highlight what is wrong with the emails. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-4535) The ability to clone into a specific directory would be useful
Jayson Minard commented on JENKINS-4535 The ability to clone into a specific directory would be useful I don't think it is a duplicate, nor solves the problem. The related issue 6357 adds an advanced setting that is NOT per Git repo. It is one advanced setting that appears to apply to all GIT repo's evenly. So you still end up with them pulling on top of each other to the same location, yes? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15879) Tag this build does not work for 'partial checkouts'
Valentin Batz updated JENKINS-15879 Tag this build does not work for 'partial checkouts' Change By: Valentin Batz (20/Nov/12 8:38 PM) Description: When checking out // as a module and trying to tag the build,this error message occurs:cvsnt rtag: cannot find module `' - ignoredSo all the single files that are checked out as modules don't get tagged. There were multiple checkout modules configured in the job. Some were just the module, some modules with subdirs and of course the single file checkouts. Let me know if you require more information to reproduce the issue. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15860) Mail body for two simultaneous mails get mixed
Xavier Nodet commented on JENKINS-15860 Mail body for two simultaneous mails get mixed I received two different emails, from two different failing jobs. email 1: Sent 2012-11-18 07:01 Subject: static_code_tests-x64_sles10 - Build # 45 - Failure! Body: [what you saw in the comment above] email 2: Sent 2012-11-18 07:01 Subject: check-unmerged-commits - Build # 15 - Failure! Body: [again what you saw in the comment above] Email 1 should have had an entirely different body (albeit built from the same template). The second email had the correct body, but the first email had exactly the same! Sorry for my lack of clarity. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15860) Mail body for two simultaneous mails get mixed
Slide-O-Mix commented on JENKINS-15860 Mail body for two simultaneous mails get mixed From looking at the code, I'm not sure how this is possible, or how to debug this. I can't really cause two emails to be generated simultaneously...I'll continue looking to see what I can come up with. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15872) Running 'rlog' after 'cvs up -r TAG' superfluous & giving incorrect change log for the workspace
Akhil Mittal updated JENKINS-15872 Running 'rlog' after 'cvs up -r TAG' superfluous & giving incorrect change log for the workspace Please note that head has moved since then to 1.23 Change By: Akhil Mittal (20/Nov/12 9:09 PM) Attachment: rlog.txt This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15860) Mail body for two simultaneous mails get mixed
Xavier Nodet commented on JENKINS-15860 Mail body for two simultaneous mails get mixed My first intuition (but I didn't look at the code at all) would be that two threads generate mails at the same time. Each is created by Jenkins, not the email-ext plugin. So from the plugin point-of-view, there is only one mail. But then these two threads would use the same variable that is used to generate the body of the mail. And then the second thread, when generating its body, would overwrite the body generated by the first thread. This would fit the symptoms, but of course I may be completely off-track... This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15860) Mail body for two simultaneous mails get mixed
Slide-O-Mix commented on JENKINS-15860 Mail body for two simultaneous mails get mixed There would be two different instances of the publisher, one for each job. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15860) Mail body for two simultaneous mails get mixed
Xavier Nodet commented on JENKINS-15860 Mail body for two simultaneous mails get mixed I'm not sure this is enough to safely run some code like e.g. ExtendedEmailPublisher.getContent(...) from two threads simultaneously. If I'm not mistaken, such a method is not thread-safe by default: it would have to be 'synchronized'. As it's not, the two instances may call this method at the same time, and thus use a single set of 'text', 'messageContentType' and 'msgPart' variables. Did I miss something? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15860) Mail body for two simultaneous mails get mixed
Slide-O-Mix commented on JENKINS-15860 Mail body for two simultaneous mails get mixed Why would it need to be synchronized? It is a method that is run in two separate instances of the class. I don't see anything in there that is static or shared between two difference instances of the class. The internal variables would not be shared between two instances of the class. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15884) Release resource not running when a build step fails
Henrique Gontijo created JENKINS-15884 Release resource not running when a build step fails Issue Type: Bug Assignee: Unassigned Components: exclusion Created: 20/Nov/12 10:18 PM Description: Given a build using Exclusion plugin and the following the build steps defined: -Critical block start -My build steps. In my example I'm using Trigger plugin to trigger others jobs. -Critical block end When one of the build steps fails, critical block end is not being executed and the resource still locked. An another attempt was trying to remove Critical block end, since plugin's documentation says if there's no Critical block end, the resource release will always be executed. I tried without success. Project: Jenkins Priority: Major Reporter: Henrique Gontijo This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15881) svn revision check failed when checking out older revision after HEAD build
kutzi commented on JENKINS-15881 svn revision check failed when checking out older revision after HEAD build How do you manage do build an older revision in a later build? Do you pass the revision as a build parameter? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15170) SVN hangs after update. Performing thread dump a few times fixes.
kutzi resolved JENKINS-15170 as Incomplete SVN hangs after update. Performing thread dump a few times fixes. Change By: kutzi (20/Nov/12 10:51 PM) Status: Open Resolved Resolution: Incomplete This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15885) Not able to any configutation changes for existing jobs and new jobs
viral shah created JENKINS-15885 Not able to any configutation changes for existing jobs and new jobs Issue Type: Bug Affects Versions: current Assignee: jieryn Attachments: Jenkins.png Components: configure-job-column Created: 21/Nov/12 12:16 AM Description: Hi Support, I'm not able to configure any jobs via clicking the configuration link for every job. Please see the image for error as When click on configure page is not loading fully and not able to do any changes for login details and project path and build name etc. Due Date: 23/Nov/12 12:00 AM Project: Jenkins Priority: Blocker Reporter: viral shah This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-9135) Not possible edit a Jobs Configuration
viral shah commented on JENKINS-9135 Not possible edit a Jobs Configuration I'm having the same issue with new version of jenkins as not able to do any changes via configuration as page has the text loading and it is not doing any thing . This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15665) More Link broken
Robert Lachner closed JENKINS-15665 as Fixed More Link broken Change By: Robert Lachner (21/Nov/12 7:54 AM) Status: Resolved Closed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15621) Publish over CIFS plugin suddenly stopped working
Robert Lachner closed JENKINS-15621 as Fixed Publish over CIFS plugin suddenly stopped working Change By: Robert Lachner (21/Nov/12 7:53 AM) Status: Open Closed Fix Version/s: current Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15621) Publish over CIFS plugin suddenly stopped working
Robert Lachner commented on JENKINS-15621 Publish over CIFS plugin suddenly stopped working Hi, after some update its working again. But i couldnt find out what was wrong with it. Robert This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15665) More Link broken
Robert Lachner resolved JENKINS-15665 as Fixed More Link broken was fixed with Jenkins 1.491 Change By: Robert Lachner (21/Nov/12 7:54 AM) Status: Open Resolved Fix Version/s: current Resolution: Fixed This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
[JIRA] (JENKINS-15886) parameterized builds start default ant target in Ant-Task
Robert Lachner created JENKINS-15886 parameterized builds start default ant target in Ant-Task Issue Type: Bug Affects Versions: current Assignee: huybrechts Components: ant, parameterized-trigger Created: 21/Nov/12 7:58 AM Description: Hi, any parameterized build that has an ant builder only starts the default ant target and completely ignores the given target in the ant builder options. So if we have a parameterized build that has to use ant builders we are forced to use the default target or remove the parameter option. Environment: Windows Server 2008 R2 Ant 1.8.3 Jenkins 1.491 Project: Jenkins Priority: Critical Reporter: Robert Lachner This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira
