Cannot patch file in a checkout directory

I'm having trouble running the build after I changed the checkout directory to a network location (mapped as T:\TeamCity on TC server and TC agent). This directory is completely empty before the build starts, and I can see in the build log that TeamCity (reduntantly) cleans that directory during the build:


Research\CIScripts\build.xml is the location in our code repository (Perforce). The agent service runs as a network user that has full control permissions to T:\TeamCity (as far as I can tell). I am using the following client mapping for Perforce in my VCS root settings:


Here is the build agent log exerpt:

(FileOutputStream.java:179)
	at java.io.FileOutputStream.(FileOutputStream.java:131)
	at jetbrains.buildServer.vcs.patches.PatcherImpl.replaceTextUsingBytes(PatcherImpl.java:42)
	at jetbrains.buildServer.vcs.patches.AbstractPatcher.replaceText(AbstractPatcher.java:125)
	at jetbrains.buildServer.vcs.patches.AbstractPatcher$1.changeTextUsingBytes(AbstractPatcher.java:93)
	at jetbrains.buildServer.vcs.patches.AbstractPatcher$1.changeTextUsingBytes(AbstractPatcher.java:100)
	at jetbrains.buildServer.vcs.patches.LowLevelPatcher.applyPatch(LowLevelPatcher.java:83)
	at jetbrains.buildServer.vcs.patches.AbstractPatcher.applyPatch(AbstractPatcher.java:56)
	at jetbrains.buildServer.agent.impl.patch.ApplyPatch.execute(ApplyPatch.java:20)
	at jetbrains.buildServer.agent.impl.patch.GetProjectSources.applyPatch(GetProjectSources.java:231)
	at jetbrains.buildServer.agent.impl.patch.GetProjectSources.applyPathToDisc(GetProjectSources.java:204)
	at jetbrains.buildServer.agent.impl.patch.GetProjectSources.loadAndApplyPatch(GetProjectSources.java:191)
	at jetbrains.buildServer.agent.impl.patch.GetProjectSources.access$300(GetProjectSources.java:23)
	at jetbrains.buildServer.agent.impl.patch.GetProjectSources$3.execute(GetProjectSources.java:337)
	at jetbrains.buildServer.agent.impl.patch.GetProjectSources.executePatchProcess(GetProjectSources.java:132)
	at jetbrains.buildServer.agent.impl.patch.GetProjectSources.applyPatch(GetProjectSources.java:335)
	at jetbrains.buildServer.agent.impl.patch.GetProjectSources.execute(GetProjectSources.java:94)
	at jetbrains.buildServer.agent.impl.BuildAgentImpl$BuildRunAction.run(BuildAgentImpl.java:1033)
	at java.lang.Thread.run(Thread.java:595)
]]>


What is the patch file? I understand that TeamCity cannot find build.xml file because it does not exist in the checkout directory, but shouldn't TC just put it there, especially since I enabled clean build?

Any help would be appreciated.

Thanks,
Oleg.

Edited by: Oleg Gerovich on Jul 21, 2008 2:20 PM

9 comments

Try using the following client mapping in TeamCity VCS root:
//Research/CIScripts/... //team-city-agent/...

--
Pavel Sher

0

Pavel,

Thanks for the suggestion, but, unfortunately, it did not work. Here is the build log:


Moreover, I don't think that the mapping is ideal because I will have other directories and would not want them all to go to //team-city-agent/. Why is TC trying to patch one file when it should be checking out the whole specified directory? Is there a way to avoid patching?

Does TC allow the agent checkout directory to be on a network share? In my case, T:\TeamCity is not a local directory on the agent machine, but is mapped to something like
network.drive\some\folder\there.

Edited by: Oleg Gerovich on Jul 25, 2008 10:15 AM

0

I tried using the network path instead of the drive mapping, and I think I uncovered a bug. Here are the settings in the build configuration (they are different from above since this is the TC server on my own machine for testing):

Client mapping:
//Research/... //team-city-agent/Research/...

Checkout directory:

somenetworklocation\TeamCity

Path to build file in Ant runner section (build.xml is in a different location from my previous posting):
Research/build.xml

Working directory:
Research


The build fails with the following build log:


It looks like TC is assuming that the path to build file is local to the hard drive (C:), which is not the case. The update finished correctly, and all the files are there (e.g.
somenetworklocation\TeamCity\Research\build.xml is present). Can someone confirm if it's a bug, so I can file it in the issue tracker?

Has anyone been able to use a network share for checkout folder and build file location? I'd appreciate some help on this one. Thank you!

0

It seems to me that user under which agent service is running does not have enough permissions to write to T:\TeamCity. Try to launch agent via agent.bat and see what happens.

--
Pavel Sher

0

Please submit this bug to our tracker: http://jetbrains.net/tracker

--
Pavel Sher

0

Pavel,

Thanks for your suggestion. After using agent.bat, TC successfully updated T:\TeamCity with the right set of files from the repository. Seems to work fine, but using the service would be preferable (I think). Any pointers on why the agent service does not work and agent.bat works?

We are not out of the permissions woods yet though. There is a new problem - after checkout, somehow permissions on T:\TeamCity get reset to inherit from the parent directory and wipe out the permissions that I explicitly set for that folder that included the right users. Consequently, my custom build process cannot access those folders. Does TC reset/change permissions on the checkout directory during the build? This might be something related to our network (IT is looking into it), but I thought that it wouldn't hurt to ask here.

0

I suggested to use agent.bat to investigate whether problem is in user permissions or in TeamCity. Now it looks like user account used by the agent service does not have enough permissions to write to T:\TeamCity. You can see what user account is used or change it in the agent service properties.

The permissions set on the files in working directory depends on the user account under which agent is working. So it seems to me you should take a closer look at agent user account settings.

--
Pavel Sher

0

I think I discovered why TC cannot find the files on a mapped drive. Per this article from Microsoft, services should not access mapped drives, but use UNC paths instead. Hence the failure to find drive T: in my TC setup... :( If you guys fix TW-5518, it would really make my (and possibly others') life easier. Interested readers, please vote in the issue tracker for this feature.

0

Please sign in to leave a comment.