[JIRA] [svnmerge-plugin] (JENKINS-26347) Credentials not found for merge from mainline
Greg Hansen commented on JENKINS-26347 Credentials not found for merge from mainline Sorry, didn't see that you'd asked questions. Here you go: Run on a slave: yes Slave is a CentOS 5.8 machine (needed by our product build) Protocol is HTTPS Master is not configured to be able to run the build, it's running CentOS 6. Thanks for looking at this! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [mask-passwords-plugin] (JENKINS-26421) Password masking is masking even string fields
Greg Hansen updated JENKINS-26421 Password masking is masking even string fields Change By: Greg Hansen (03/Feb/15 4:17 PM) Attachment: JenkinsMaskPassword272a.PNG This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [mask-passwords-plugin] (JENKINS-26421) Password masking is masking even string fields
Greg Hansen updated JENKINS-26421 Password masking is masking even string fields Change By: Greg Hansen (03/Feb/15 4:23 PM) Attachment: JenkinsMaskPassword272b.PNG This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [mask-passwords-plugin] (JENKINS-26421) Password masking is masking even string fields
Greg Hansen edited a comment on JENKINS-26421 Password masking is masking even string fields I'm seeing this also. Jenkins 1.595, Mask Password plugin 2.7.2. It's masking string parameters, even simple numbers. See attachment. I've had to turn off password masking on all projects so I had a hope of reading the console logs. I can't disable the envinject plugin and get a build, so I can't tell you what the result is. I've also attached a screenshot of the result of disabling masking, which unfortunately also leaves passwords exposed. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [mask-passwords-plugin] (JENKINS-26421) Password masking is masking even string fields
Greg Hansen commented on JENKINS-26421 Password masking is masking even string fields I'm seeing this also. Jenkins 1.595, Mask Password plugin 2.7.2. It's masking string parameters, even simple numbers. See attachment. I've had to turn off password masking on all projects so I had a hope of reading the console logs. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [svnmerge-plugin] (JENKINS-26347) Credentials not found for merge from mainline
Greg Hansen commented on JENKINS-26347 Credentials not found for merge from mainline Ah, thank you, I missed that distinction. I see that you have released 2.5 of the Merge plugin, so I'm giving that a try. Thanks for the fast response! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [svnmerge-plugin] (JENKINS-26347) Credentials not found for merge from mainline
Greg Hansen edited a comment on JENKINS-26347 Credentials not found for merge from mainline Ah, thank you, I missed that distinction. I see that you have released 2.5 of the Merge plugin, so I'm giving that a try. Thanks for the fast response! No joy, but at least it's a different error. Subversion plugin 2.5, svnmerge plugin 2.5, Jenkins 1.595. I'm running against a Subversion 1.6 repo, if that makes a difference. = 13:38:27 EnvInject - Variables injected successfully. 13:38:28 Updating workspace to the latest revision 13:38:33 At revision 44571 13:38:34 FATAL: null 13:38:34 java.lang.NullPointerException 13:38:34 at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.parseDir(SVNWCDb.java:1848) 13:38:34 at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.obtainWcRoot(SVNWCDb.java:6245) 13:38:34 at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.readInfo(SVNWCDb.java:3531) 13:38:34 at org.tmatesoft.svn.core.internal.wc17.db.SVNWCDb.readInfo(SVNWCDb.java:3527) 13:38:34 at org.tmatesoft.svn.core.internal.wc17.SVNWCContext.getNodeUrl(SVNWCContext.java:1088) 13:38:34 at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.getTargetURL(SvnNgRepositoryAccess.java:234) 13:38:34 at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgRepositoryAccess.createRepositoryFor(SvnNgRepositoryAccess.java:33) 13:38:34 at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:46) 13:38:34 at org.tmatesoft.svn.core.internal.wc2.remote.SvnRemoteGetInfo.run(SvnRemoteGetInfo.java:31) 13:38:34 at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:21) 13:38:34 at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1259) 13:38:34 at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) 13:38:34 at org.tmatesoft.svn.core.wc.SVNWCClient.doInfo(SVNWCClient.java:2523) 13:38:34 at jenkins.plugins.svnmerge.FeatureBranchProperty$1.invoke(FeatureBranchProperty.java:201) 13:38:34 at jenkins.plugins.svnmerge.FeatureBranchProperty$1.invoke(FeatureBranchProperty.java:172) 13:38:34 at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2677) 13:38:34 at hudson.remoting.UserRequest.perform(UserRequest.java:121) 13:38:34 at hudson.remoting.UserRequest.perform(UserRequest.java:49) 13:38:34 at hudson.remoting.Request$2.run(Request.java:324) 13:38:34 at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68) 13:38:34 at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) 13:38:34 at java.util.concurrent.FutureTask.run(FutureTask.java:166) 13:38:34 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) 13:38:34 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 13:38:34 at java.lang.Thread.run(Thread.java:724) 13:38:34 at ..remote call to jenkins-slave023(Native Method) 13:38:34 at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1356) 13:38:34 at hudson.remoting.UserResponse.retrieve(UserRequest.java:221) 13:38:34 at hudson.remoting.Channel.call(Channel.java:752) 13:38:34 at hudson.FilePath.act(FilePath.java:970) 13:38:34 at hudson.FilePath.act(FilePath.java:959) 13:38:34 at jenkins.plugins.svnmerge.FeatureBranchProperty.rebase(FeatureBranchProperty.java:172) 13:38:34 at jenkins.plugins.svnmerge.RebaseAction.perform(RebaseAction.java:115) 13:38:34 at jenkins.plugins.svnmerge.RebaseBuilder.perform(RebaseBuilder.java:50) 13:38:34 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) 13:38:34 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770) 13:38:34 at hudson.model.Build$BuildExecution.build(Build.java:199) 13:38:34 at hudson.model.Build$BuildExecution.doRun(Build.java:160) 13:38:34 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:533) 13:38:34 at hudson.model.Run.execute(Run.java:1759) 13:38:34 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) 13:38:34 at hudson.model.ResourceController.execute(ResourceController.java:89) 13:38:34 at hudson.model.Executor.run(Executor.java:240) This message is automatically generated by JIRA. If you think it
[JIRA] [svnmerge-plugin] (JENKINS-26347) Credentials not found for merge from mainline
Greg Hansen created JENKINS-26347 Credentials not found for merge from mainline Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: svnmerge-plugin Created: 08/Jan/15 10:01 PM Description: svnmerge plugin 2.4, jenkins 1.595, matrix-based access control (with additional boxes checked), single module. At the build step "Rebase with upstream Subversion revision" set to "Latest revision", I get the error: 13:24:06 EnvInject - Executing scripts and injecting environment variables after the SCM step. ... 13:24:06 EnvInject - Variables injected successfully. 13:24:06 FATAL: hudson.scm.SubversionSCM.createAuthenticationProvider(Lhudson/model/AbstractProject;Lhudson/scm/SubversionSCM$ModuleLocation;)Lorg/tmatesoft/svn/core/auth/ISVNAuthenticationProvider; 13:24:06 java.lang.NoSuchMethodError: hudson.scm.SubversionSCM.createAuthenticationProvider(Lhudson/model/AbstractProject;Lhudson/scm/SubversionSCM$ModuleLocation;)Lorg/tmatesoft/svn/core/auth/ISVNAuthenticationProvider; 13:24:06 at jenkins.plugins.svnmerge.FeatureBranchProperty.rebase(FeatureBranchProperty.java:162) 13:24:06 at jenkins.plugins.svnmerge.RebaseAction.perform(RebaseAction.java:115) 13:24:06 at jenkins.plugins.svnmerge.RebaseBuilder.perform(RebaseBuilder.java:50) 13:24:06 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) 13:24:06 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770) 13:24:06 at hudson.model.Build$BuildExecution.build(Build.java:199) 13:24:06 at hudson.model.Build$BuildExecution.doRun(Build.java:160) 13:24:06 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:533) 13:24:06 at hudson.model.Run.execute(Run.java:1759) 13:24:06 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) 13:24:06 at hudson.model.ResourceController.execute(ResourceController.java:89) 13:24:06 at hudson.model.Executor.run(Executor.java:240) I'm not sure what this error is telling me. The original sync from the feature branch worked flawlessly. It would appear that it's trying to do some new authentication for the merge, but it's not clear why it's not getting credentials to use. Wouldn't it just be using the credentials from the feature branch sync? Environment: jenkins 1.595, svnmerge 2.4, CentOS 6.3, Firefox, Oracle java 1.7 Project: Jenkins Priority: Critical Reporter: Greg Hansen This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [svnmerge-plugin] (JENKINS-26280) Missing Integrate Branch from feature branch builds
Greg Hansen edited a comment on JENKINS-26280 Missing Integrate Branch from feature branch builds (deleted my comment, made it a separate issue instead, sorry for the spam) This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [svnmerge-plugin] (JENKINS-26280) Missing Integrate Branch from feature branch builds
Greg Hansen commented on JENKINS-26280 Missing Integrate Branch from feature branch builds svnmerge plugin 2.4, jenkins 1.595, matrix-based access control (with additional boxes checked), single module. At the build step "Rebase with upstream Subversion revision" set to "Latest revision", I get the error: 13:24:06 EnvInject - Executing scripts and injecting environment variables after the SCM step. 13:24:06 EnvInject - Injecting as environment variables the properties content 13:24:06 GIGA_MODEL=hdccv1 13:24:06 GIGA_TARGET=debug 13:24:06 GIGA_OPTIONS=None 13:24:06 GIGA_CODE=hdccv1 13:24:06 GIGA_BUILD_CODE=GVHD 13:24:06 GIGA_PRODUCT_DIR=gvhd 13:24:06 GIGA_SMART= 13:24:06 13:24:06 EnvInject - Variables injected successfully. 13:24:06 FATAL: hudson.scm.SubversionSCM.createAuthenticationProvider(Lhudson/model/AbstractProject;Lhudson/scm/SubversionSCM$ModuleLocation;)Lorg/tmatesoft/svn/core/auth/ISVNAuthenticationProvider; 13:24:06 java.lang.NoSuchMethodError: hudson.scm.SubversionSCM.createAuthenticationProvider(Lhudson/model/AbstractProject;Lhudson/scm/SubversionSCM$ModuleLocation;)Lorg/tmatesoft/svn/core/auth/ISVNAuthenticationProvider; 13:24:06 at jenkins.plugins.svnmerge.FeatureBranchProperty.rebase(FeatureBranchProperty.java:162) 13:24:06 at jenkins.plugins.svnmerge.RebaseAction.perform(RebaseAction.java:115) 13:24:06 at jenkins.plugins.svnmerge.RebaseBuilder.perform(RebaseBuilder.java:50) 13:24:06 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20) 13:24:06 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:770) 13:24:06 at hudson.model.Build$BuildExecution.build(Build.java:199) 13:24:06 at hudson.model.Build$BuildExecution.doRun(Build.java:160) 13:24:06 at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:533) 13:24:06 at hudson.model.Run.execute(Run.java:1759) 13:24:06 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43) 13:24:06 at hudson.model.ResourceController.execute(ResourceController.java:89) 13:24:06 at hudson.model.Executor.run(Executor.java:240) I'm not sure what this error is telling me. The original sync from the feature branch worked flawlessly. It would appear that it's trying to do some new authentication for the merge, but it's not clear why it's not getting credentials to use. Wouldn't it just be using the credentials from the feature branch sync? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [svnmerge-plugin] (JENKINS-26280) Missing Integrate Branch from feature branch builds
Greg Hansen edited a comment on JENKINS-26280 Missing Integrate Branch from feature branch builds I am running 2.4. See JENKINS-26347 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [svnmerge-plugin] (JENKINS-26280) Missing Integrate Branch from feature branch builds
Greg Hansen commented on JENKINS-26280 Missing Integrate Branch from feature branch builds I am running 2.4 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [subversion] (JENKINS-2717) svn polling without checkout or update
Greg Hansen commented on JENKINS-2717 svn polling without checkout or update I have a single parent project that gets a build number and queries Subversion for the head version, then passes these two values to 15 child processes (all of which work in parallel) that do their own checkouts, each at the same revision. I'd like to be able to trigger the parent project on an SCM change to the particular branch it's watching, without having to do the sync (which is about 7GB). Definitely NOT a 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [subversion] (JENKINS-12666) Subversion fails first revision check
Greg Hansen commented on JENKINS-12666 Subversion fails first revision check Not entirely sure, but we think this was resolved by going to one of the projects, where there was a red message asking if we wanted to supply credentials. Did that for one project, and the red message disappeared from all projects. A test run seems to have gotten past that point. This was after reverting to Jenkins 1.519, Subversion plugin 1.54, and removing the Matrix Role Based Access plugin and Active Directory 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [subversion] (JENKINS-12666) Subversion fails first revision check
Greg Hansen commented on JENKINS-12666 Subversion fails first revision check The prior version was 1.519 with the 1.50 Subversion 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [subversion] (JENKINS-12666) Subversion fails first revision check
Greg Hansen
commented on JENKINS-12666
Subversion fails first revision check
I'm running Jenkins 1.555 with SVN plugin 2.2, and get the same thing. New commits cause a failure, re-runs with no further commits succeed. I do have repo@${revision} in my SVN URL, as above. Revision is set to the value HEAD when these fail. Have not tried setting a specific revision.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
You received this message because you are subscribed to the Google Groups Jenkins Issues group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[JIRA] [subversion] (JENKINS-12666) Subversion fails first revision check
Greg Hansen commented on JENKINS-12666 Subversion fails first revision check I tried going back to SVN plugin 1.5; no joy. I then went back to the Jenkins version that had been running for a while (will have to add revision if I revert again), still got errors. This had been running flawlessly until I tried the upgrade, so I'm wondering if some data structure was changed by the upgrade. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [subversion] (JENKINS-13835) E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request
Greg Hansen commented on JENKINS-13835 E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request Just to close the loop, what I have found is that this issue is related to garbage collection in the underlying JVM. I installed the monitoring plugin that uses JavaMelody (see https://wiki.jenkins-ci.org/display/JENKINS/Monitoring), and if I trigger two successive garbage collections before the build of the builds run, then I don't get this error any more. (The clue came from this post: http://jenkins-ci.361315.n4.nabble.com/Hudson-garbage-collection-on-schedule-td3050696.html). From looking at the graphs generated by the plugin, what seems to happen is that if there is too much VM available, then the amount of time that garbage collection takes when it finally is triggered exceeds the amount of time required to maintain the connection to SVN. I have not characterized the times involved, just noted empirically that starting my daily builds runs with the smallest amount of VM possible seems to help a lot. Maybe there's such a thing as having too much VM? Perhaps mention of this could be made in the "setting up Jenkins" articles? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [subversion] (JENKINS-13835) E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request
Greg Hansen edited a comment on JENKINS-13835 E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request Just to close the loop, what I have found is that this issue is related to garbage collection in the underlying JVM. I installed the monitoring plugin that uses JavaMelody (see https://wiki.jenkins-ci.org/display/JENKINS/Monitoring), and if I trigger two successive garbage collections before the bulk of the builds run, then I don't get this error any more. (The clue came from this post: http://jenkins-ci.361315.n4.nabble.com/Hudson-garbage-collection-on-schedule-td3050696.html). From looking at the graphs generated by the plugin, what seems to happen is that if there is too much VM available, then the amount of time that garbage collection takes when it finally is triggered exceeds the amount of time required to maintain the connection to SVN. I have not characterized the times involved, just noted empirically that starting my daily builds runs with the smallest amount of VM possible seems to help a lot. Maybe there's such a thing as having too much VM? Perhaps mention of this could be made in the "setting up Jenkins" articles? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [subversion] (JENKINS-18217) org.tmatesoft.svn.core.SVNException: svn: E204900
Greg Hansen commented on JENKINS-18217 org.tmatesoft.svn.core.SVNException: svn: E204900 You might look at my comment in JENKINS-13835, may be related. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [subversion] (JENKINS-17768) Repository URL with parameter triggers failure of the field checker
Greg Hansen commented on JENKINS-17768 Repository URL with parameter triggers failure of the field checker This is similar to 18714 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [subversion] (JENKINS-17768) Repository URL with parameter triggers failure of the field checker
Greg Hansen edited a comment on JENKINS-17768 Repository URL with parameter triggers failure of the field checker This is similar to JENKINS-18714 This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [subversion] (JENKINS-13835) E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request
Greg Hansen commented on JENKINS-13835 E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request I'm on a VM, I'm hoping that's not the issue. The VM is configured with 4 virtual cpus (each Intel E5-2650 at 2.0 GHz), 8 GB RAM, and 10K RPM SAS drives. We just bought the servers a month or two ago, and from examining the performance logs of the VMware vSphere Center, I'm barely using 8% of the cpu available, max. The SVN server is hardware that's a couple of years old, but I'm getting those on newer hardware too (the 1.8 installation I mentioned). We're currently running SVN 1.6 in our repos, so the 1.7 issue isn't it. Good thought, though! I haven't looked at the Jenkins GC options. I'll research that. It would make sense if it jumped in and hogged the server for long periods of time, which is likely given that I'm running 27 projects/day. I did bump the timeout to 10 minutes on both sides (both the SVN machine and the Jenkins slave that's doing the checkout); all that did is make it wait longer to time out. If it helps any, here's my latest call stack: ERROR: Failed to check out https://gigasrc.gigamon.com/repos/gv_g/mainline/gv216 org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT /repos/!svn/vcc/default failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:379) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:364) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:708) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:335) 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:192) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:76) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:752) 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:1235) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:777) at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:99) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:153) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:903) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:884) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:867) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2388) 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(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) Caused by: svn: E175002: REPORT /repos/!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) ... 32 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT request failed on '/repos/!svn/vcc/default' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
[JIRA] [subversion] (JENKINS-13835) E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request
Greg Hansen commented on JENKINS-13835 E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request Just tried this with a new installation of the latest version of Subversion server (1.8) on a freshly-installed machine running CentOS 6.3, and get the same error. We tried increasing the "KeepAlive" timeout from 15 seconds to 60 seconds, but still observed 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [subversion] (JENKINS-13835) E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request
Greg Hansen edited a comment on JENKINS-13835 E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request Just tried this with a new installation of the latest version of Subversion server (1.8) on a freshly-installed machine running CentOS 6.3, and get the same error. We tried increasing the "KeepAlive" timeout from 15 seconds to 60 seconds (restarted both httpd and jenkins), but still observed 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 -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [subversion] (JENKINS-13835) E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request
Greg Hansen commented on JENKINS-13835 E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request I'm grasping at anything that might alleviate the situation. Configuring httpd to maintain an established connection for a while to see if there was any more activity that could be sent across it before dismantling sounded like a reasonable thing to try. From the experiment where I ran the same check-outs against both a revision 1.6 repo and a newly-installed 1.8 repo (Dell R620, two six-core processors, 32 GB RAM, 10K RPM SAS drives, CentOS 6.3), the fact that the problem occurs on both repos suggests that the problem is not on the Subversion side it's on the Jenkins server side. Anyone with suggestions about Jenkins or CentOS configuration that might help this, please speak up! It's killing one or two out of 23 builds every day. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [subversion] (JENKINS-13835) E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request
Greg Hansen commented on JENKINS-13835 E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request I bumped the timeout to five minutes, and now ten. We'll see if that helps. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] [subversion] (JENKINS-13835) E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request
Greg Hansen commented on JENKINS-13835 E175002 in org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request Jenkins version 1.519 Jenkins Subversion plugin version 1.50 CentOS 6.3 x86_64 ERROR: Failed to check out https://gigasrc.gigamon.com/repos/gv_g/branches/gv_8300/gs org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT /repos/!svn/vcc/default failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:379) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:364) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:352) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:708) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:335) 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:192) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.update(SvnNgAbstractUpdate.java:76) at org.tmatesoft.svn.core.internal.wc2.ng.SvnNgAbstractUpdate.checkout(SvnNgAbstractUpdate.java:752) 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:1235) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:777) at hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:99) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:153) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:903) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:884) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:867) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2388) 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(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) Caused by: svn: E175002: REPORT /repos/!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) ... 32 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: REPORT request failed on '/repos/!svn/vcc/default' svn: E175002: SSL peer shut down incorrectly 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.http.HTTPConnection._request(HTTPConnection.java:754) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) ... 31 more Caused by: svn: E175002: REPORT request failed on '/repos/!svn/vcc/default' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:752) ... 32 more Caused by: svn: E175002: SSL peer shut down incorrectly at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:109) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:505) ... 32 more Caused by: javax.net.ssl.SSLException: SSL peer shut down incorrectly at com.sun.net.ssl.internal.ssl.InputRecord.readV3Record(Unknown Source) at
[JIRA] [subversion] (JENKINS-1241) force using HEAD SVN version for build
Greg Hansen commented on JENKINS-1241 force using HEAD SVN version for build I like tonylampada2's solution. I have several independent builds that I'd like to all use the same revision so they are consistent (the builds are for different products, but all products would like to use the same revision of the underlying code). I tried putting in a pre-SCM-checkout step to set a variable from a web service, but the SVN checkout did not pick up the change in the value of the variable. I tried making the build parameterized, and triggering it from a prior build that set the parameter from the web service, but the value doesn't get passed (yes, I checked that the environment should pass in). I tried not having parameters, which also failed. Does anyone know how to set a parameter to that will be passed to the SVN plugin from an external source? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
