Re: TFS plugin mapping conflict
I had issues when the workspaces already existed in 3.2.0 - see https://issues.jenkins-ci.org/browse/JENKINS-30355 Not sure if this is the same as your issue - in my case deleting the old workspaces first solved the issue. After that I ran into a number of other issues with the 4.0.0 plug-in and downgraded back to 3.2.0 Regards, Stefan On Tuesday, 1 December 2015 00:59:14 UTC+1, Andy Falanga wrote: > > Hello all, > > I recently updated my TFS plugin to version 4.0.0 to take advantage of the > Java client instead of having to install a tf client on all my Linux > hosts. I have two Linux build agents and the Jenkins server runs on > Windows. I occasionally see problems like this: > > FATAL: > com.microsoft.tfs.core.clients.versioncontrol.exceptions.MappingConflictException: > The path /home/builder/jenkins/workspace/LinuxBuildCompileOnly is already > mapped in workspace Hudson-LinuxBuildCompileOnly-devlnx64-04. > > > This occurred on host devlnx64-03. What is causing this? A review of the > log shows the following: > > Deleting workspaces named 'Hudson-LinuxBuildCompileOnly-devlnx64-03' from > computer 'devlnx64-03'... > Deleted 1 workspace(s) named 'Hudson-LinuxBuildCompileOnly-devlnx64-03'. > Creating workspace 'Hudson-LinuxBuildCompileOnly-devlnx64-03' owned by > 'WINNTDOM\umtfsservice'... > Created workspace 'Hudson-LinuxBuildCompileOnly-devlnx64-03'. > Mapping '$/Project/Main' to local folder > '/home/builder/jenkins/workspace/LinuxBuildCompileOnly' in > workspace 'Hudson-LinuxBuildCompileOnly-devlnx64-03'... > > > > The process removes the old workspace and remakes it. Why is TFS > complaining about this mapping? Shouldn't it be content to allow the TFS > location to be mapped to more than one location on different systems and in > different workspaces? I'm quite curious about this and would appreciate > any insights those here might have. > > Thanks, > Andy > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/e64bc18e-a903-48d9-951c-522edecf7431%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: How is the TFS plugin supposed to checkout sources on remote nodes
I would steer away from the 4.0.0 plug-in until it is more stable. 1. a job created with 3.2.0 plugin will simply fail with 4.0.0 plugin - see https://issues.jenkins-ci.org/browse/JENKINS-30355 2. list workspaces lists all workspaces on all servers - see https://issues.jenkins-ci.org/browse/JENKINS-30330 3. (windows) slaves have been giving all sorts of NumberFormatExceptions - https://issues.jenkins-ci.org/browse/JENKINS-30382 Since installing 4.0.0 slaves were crashing frequently. On the windows slaves I uninstalled the TFS clients (VS Team Explorer) and the get latest was /generally/ working but often resulting in an unsatisified link error. Everything was (and now is again) working quite nicely with 3.2.0. On my one Linux slave the TEE client is installed. On Monday, 5 October 2015 20:36:16 UTC+2, Andy Falanga wrote: > > I've updated my TFS plugin to 4.0.0 (the latest). Jenkins is running on a > Windows system. I must build in Linux. We have 3 systems configured as > slave nodes for this purpose. The project that I configured in Jenkins did > farm the job to one of the correct slave nodes. However, although the > build log shows that all of the TFS workspaces (rather irritating that this > term is overloaded) were listed, it doesn't show that any sources were > checked out. > > I scrapped my old project because it just wasn't working correctly. I > made a "free-style software project" and put in the settings necessary to > check out code from my branch in TFS. How is this normal flow supposed to > work? Am I going to have to use the TEE client on the slave nodes? If so, > I thought that version 4.0.0 of the TFS plugin was supposed to mitigate > this? It claims to at least. I'd appreciate knowing how this is supposed > to work with remote nodes. > > Thanks for any help. > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/5d3d3f9e-94b4-423d-9f2d-2b526aa32243%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
UnsatisfiedLinkError on slaves after restart of master
Jenkins: 1.627 TFS plug-in: 4.0.0 Java: jre1.8.0_60 Intermittently multiple slaves are failing to build with: Started by user Stefan Drissen [EnvInject] - Loading node environment variables. Building remotely on in workspace c:\exact\jenkins\workspace\7.20\build work FATAL: java.io.IOException: Remote call on failed java.lang.RuntimeException: java.io.IOException: Remote call on failed at hudson.plugins.tfs.model.Server.execute(Server.java:110) at hudson.plugins.tfs.model.Project.extractChangesetNumber(Project.java:193 ) at hudson.plugins.tfs.model.Project.getRemoteChangesetVersion(Project.java: 189) at hudson.plugins.tfs.model.Project.getRemoteChangesetVersion(Project.java: 205) at hudson.plugins.tfs.TeamFoundationServerScm. recordWorkspaceChangesetVersion(TeamFoundationServerScm.java:262) at hudson.plugins.tfs.TeamFoundationServerScm.checkout( TeamFoundationServerScm.java:211) at hudson.model.AbstractProject.checkout(AbstractProject.java:1277) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout( AbstractBuild.java:610) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java :532) at com.tikal.jenkins.plugins.multijob.MultiJobBuild$MultiJobRunnerImpl.run( MultiJobBuild.java:134) at hudson.model.Run.execute(Run.java:1741) at com.tikal.jenkins.plugins.multijob.MultiJobBuild.run(MultiJobBuild.java: 73) at hudson.model.ResourceController.execute(ResourceController.java:98) at hudson.model.Executor.run(Executor.java:408) Caused by: java.io.IOException: Remote call on failed at hudson.remoting.Channel.call(Channel.java:786) at hudson.plugins.tfs.model.Server.execute(Server.java:106) ... 14 more Caused by: java.lang.UnsatisfiedLinkError: com.microsoft.tfs.jni.internal. platformmisc.NativePlatformMisc.nativeGetEnvironmentVariable(Ljava/lang/ String;)Ljava/lang/String; A restart of the slave (Windows 2008r2 - started as a Windows scheduled task) solves the issue (for a while). Why? The 4.0.0 version of the TFS plug-in is supposed to be putting the tfs sdk in a place available for the slave - I have to admit that after searching the machine I cannot find it - but since a restart of the slave solves the issue, it must be somewhere. The issue *seems* to manifest after a restart of the master Jenkins service (running on Windows 8.1 x64). Best regards, Stefan -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/c54df0e7-b957-4f9d-b224-3914da966cdb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
