I have a bat file in which I perform the copying folder from my computer to a remote computer in a shared folder. If I run it on your computer from the command line, everything works. If I add this bat file TeamCity it gives an error "error in Access." If I instead of the path to the shared folder write path to a folder on my computer, it is normally all copies TeamCity.
so looks bat file when copying to the local computer
cls
SET ARTPATH="C:\myfolder\"
cd %ARTPATH%
xcopy DatabaseUpgrader /e /Y C:\example\
cd c:\
so looks bat file when copying to a remote computer in a shared folder
cls
SET ARTPATH="C:\myfolder\"
SET DBPATH=\\10.73.0.3\DBUpdater\DatabaseUpgrader\
cd %ARTPATH%
xcopy DatabaseUpgrader /e /Y %DBPATH%
folder DBUpdater now shared all network users. I think that launches White TeamCity file under the user has no rights. how to fix it but do not know
If your build agent is installed as a service, try the following:
Run the service under account that has enough rights for the share, by default it is installed under SYSTEM account that can't go outside of the box.
Change agent installation from service to console app, here's a TeamCity doc saying that you need to do it to access network shares: http://confluence.jetbrains.com/display/TCD8/Known+Issues#KnownIssues-Windowsservicelimitations
My knowledge of Windows is very poor, but try to compare the permissions of these two users (the one that you are logged in as, and the second that TC agent is run by).
Related
I accidentally removed all permissions from a directory on a Windows 2008 server. I can see the directory when listing contents of its parent both through Windows Explorer and DOS, but I can't do anything else. No matter what I try, the system essentially acts like I'm trying to work with a directory that doesn't exist. Trying to change the permissions through Windows Explorer yields a message that the security information is not available (on the Security tab). I've also tried takeown and modifying permissions with icacls, both of which report file not found. My account is part of the Administrators group. The account that created the folder (the owner before I messed up the permissions) can't even see the directory when listing contents of its parent. dir /q reports the owner of the directory as "...". Is there anything that can be done here or is this directory lost?
The solution here was to log in using the local administrator account and run takeown /F on the directory in question. From there, I was able to reset the permissions of the directory and all of its contents.
I have a Jenkins job that calls a batch file on a ClearCase drive (V:).
My Jenkins slave agent is running as a service using a local admin account.
The Jenkins job does the follow:
cleartool startview MY_VIEW
cd /d "V:\MY_VIEW\Build"
call PrepareBuild.bat
When I run the Jenkins job, I keep getting "Access is denied." in the Console Output when it tries to call the batch file. However if I manually run the above in command prompt, it completes successfully.
I did not have this problem under Windows XP. Does anybody know why this is happening on Windows 7 (32-bit)?
Thanks.
The V:\ is a virtual drive obtained with the windows command subst.
It is a shortcut between the root directory of your dynamic view (M:\yourView) and the virtual drive.
(Ie, V:\ is not particularly linked to ClearCase. It is just a drive letter the user wishes to associate to a certain ClearCase view root directory)
However, ClearCase registers that association in the registry HKCU/software/atria/....
Which means the ClearCase session run under the local admin account for Jenkins won't know about said association and the need to restore that virtual drive.
A workaround would be to make that drive permanent, using psubst.
That register the drive path in [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Devices], and HKLM is accessible from all accounts.
See " How to make SUBST mapping persistent across reboots? "
I had the same problem. Had a simpler solution.
Jenkins doesn't have access to folders that only the user has access to (even though its run by the user). So the folder which is getting access denied you need to set folder permission to everyone not the user
I want to copy binaries to stage server as the last step of build. Previously I was doing it for asp.net web sites powered by IIS. There were no problems as IIS doesn't block any boundaries. Now I need to do the same for executable server application (it executes some background tasks) which blocks at least its exe file. So I need somehow to close application, update binaries and then run application again.
What is the best way to achieve it using TeamCity?
I'm seems like your staging server is a windows machine. If that's the case, I'd recommend using two executables from the PsTools Suite (PsKill and PsExec) to kill/start your process. Here's how I would set everything up in TeamCity:
Download the PsTools Suite, and copy the contents of the zip file to a folder on the build server. I'll be using C:\Program Files\PsTools in my example.
Create a batch file that kills the executable server application, copies the appropriate binaries, and starts the application again. The batch file would look something like this:
"C:\Program Files\PsTools\PsKill" -accepteula \computername -u username -p password name_of_process_to_kill.exe
copy files - I'm assuming you copied binaries to your ASP.Net staging site using the command line. If not, I can provide more details later.
"C:\Program Files\PsTools\PsExec" -accepteula \computername -u username -p password -d "path_and_name_of_executable_on_remote_server" optional_commandline_args_here
Add a new command line build step to your TeamCity build configuration that executes the batch file created in step #2.
I hope this helps!
Here is how I solved it. I added Command Line step with following Custom Script:
taskkill /IM MyApplicationProcessName /F
xcopy RelativePathToBuildBinaires PathWhereToDeployBinaries /s /e /y
start PathToMyApplicationExeInDeployFolder
Initially it didn't work as TeamCity build agent worked as service (which do not have UI). Then I disabled service and started build agent as console (by TeamCityFolder/builagent/bin/agent.bat). And it worked.
In VS 2010, I have a post-build event copying project assemblies into a common .dll folder. The .dll folder is mapped by a virtual drive (R:).
On running, I get the following: The command "copy /y "C:\CommonDLLs\Utilities.dll" "R:\"" exited with code 1.
The thing is, when I run copy /y "C:\CommonDLLs\Utilities.dll" "R:\" at the command prompt, it works correctly. I'm running VS as an admin, so I should have permissions to execute the command. Other people using the same code from source control are having no problems, but I'm stumped as to what to fix to get the copy to work correctly. Anyone have any suggestions?
EDIT: more information
The R drive is mapped/created/populated initially by a .bat script that I run as an admin as well. if I update my scripts to run to the location the R drive points to, everything runs ok, so I think this might be a drive mapping issue. The thing is, I(as a local admin) have full control over both the folder and the drive mapping.
I would guess that the virtual drive does not exist under the Admin account and as such cannot be found.
Either don't run VS as Admin, or set up the virtual drive in an command prompt running as Admin.
I want to create a post build script that moves files from the build directory to a remote (UNC) file share.
This line:
xcopy "C:\TeamCityBuild\project\WebSite\*" "\\192.168.1.1\WebSite\" /C /R /Y /E
Works fine when it is ran in a DOS-window but when TeamCitys buildrunner sln2008 tries to run it it fails with the message "Invalid drive specification"
I have shared the folder with full rights for 'Everyone' on the remote server.
Any ideas?
Just a guess. Not quite sure if it solves your problem. We had a similar problem using CruiseControl and deploying our application to remote JBoss server.
We've added
net use \\192.168.1.1\Website ...
before each copy. So that it 'mounts' the remote share before trying to access it. Note: you probably need to specify the username and password for the command (consult the command line for details).
The 'net use' seems needed even if you run the automated job as the same user you log on manually. These two kinds of sessions seem not to share remote shares information.
I've never used TeamCity Buildrunner sln2008, but if it runs as a service, then it is probably running under the "Local System" account, which doesn't have network access. Change the service properties (under the "Log On" tab) so that the service logs on as a user with permissions to that network share.
I don't beleave it works because the agent is running as a system service so it has limited network access (I beleave).
Instead of trying to use a post build step to copy the output, I think you should look into using TeamCity's Build Artifact's. That's what we use at my work altho we are new to TeamCity as well. What I don't know is if Build Artifact system will do extactly what you want.
You could try nANT
http://nant.sourceforge.net/release/latest/help/tasks/copy.html