I'm trying to setup Standard Lab Environment with TFS 2012 utilizing Build-Deploy-Test workflow. I setup test controller and test agents but when the LabManagement workflow starts executing I get an exception on RunDeploymentTask activity
Initial Property Values
BuildLocation = \\S0503TFS2T\TFSPlayground\ConsoleApplicationBuild\ConsoleApplicationBuild_20121210.23
DeploymentScriptDetails = agent1 | "$(BuildLocation)\Deploy.bat" $(BuildLocation) | c:\Env
LabEnvironmentUri = vstfs:///LabManagement/LabEnvironment/4
MaxWaitTime = 00:30:00
ThrowOnError = True
UseRoleForDeployment = True
Deployment Task Logs for Machine: win7testagent1
Access is denied
Exception Message: Team Foundation Server could not complete the deployment task for machine 'win7testagent1', script '"\\S0503TFS2T\TFSPlayground\ConsoleApplicationBuild\ConsoleApplicationBuild_20121210.23\Deploy.bat"', arguments '\\S0503TFS2T\TFSPlayground\ConsoleApplicationBuild\ConsoleApplicationBuild_20121210.23' and working directory 'c:\Env'. (type LabDeploymentProcessException)
Exception Stack Trace:
Server stack trace:
at Microsoft.TeamFoundation.Lab.Workflow.Activities.RunDeploymentTask.ExecuteDeploymentTask.RunCommand(AsyncState state)
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)
Exception rethrown at [0]:
at System.Runtime.Remoting.Proxies.RealProxy.EndInvokeHelper(Message reqMsg, Boolean bProxyCase)
at System.Runtime.Remoting.Proxies.RemotingProxy.Invoke(Object NotUsed, MessageData& msgData)
at System.Action`1.EndInvoke(IAsyncResult result)
at Microsoft.TeamFoundation.Lab.Workflow.Activities.RunDeploymentTask.ExecuteDeploymentTask.EndExecute(AsyncCodeActivityContext context, IAsyncResult result)
at System.Activities.AsyncCodeActivity.CompleteAsyncCodeActivityData.CompleteAsyncCodeActivityWorkItem.Execute(ActivityExecutor executor, BookmarkManager bookmarkManager)
Apparently, this is security issue, that i cannot get over it
Here's how this process is explained by MSDN:
The build-deploy-test workflow starts a build, and then gets the deployment scripts.
The build definition copies the build files to the drop location.
The workflow runs each deployment script in the working directory of the specific machine or machine role that the script is assigned to.
Each deployment script retrieves build files from the drop location.
Each deployment script copies or installs the specified build files onto machines in the lab environment.
At this point the problem shows up - the workflow runs each deployment script in the working directory of the specific machine.
Both machines are in the same domain the user that runs the Build service is also in the administrators group in the remote machine. I have even shared the remote folder where the workflow is supposed to copy the files/script with everyone in the network but no luck again.
I'm doing something stupid that driving me crazy - any help or thoughts are greatly appreciated!
Best,
Rado
The following solution may fix your problem.
Steps: Create local account on the following server: local lab service account - tfslab
tfs test controller server: create local tfslab account. Also configure the tfslab as lab service account in test controller configure console
tfs test agent server: create local tfslab account and add tfslab to local admin group. Also update Visual Studio Test Agent service and Visual Studio Lab Agent Service to run as tfslab.
tfs drop folder server: create local tfslab account. And add share read permission to tfs drop folder.
Details discussion see here.
You may try to check %ErrorLevel% at the last of your bat script. I met the same error, and it turned out that that error was caused by exit code of robocopy, which returns 1 when the copy successes. I set the error code to 0, the issue was fixed.
Related
I have changed our Jenkins setup from everything running on one machine to a master-agent/slave setup. Before that everything worked fine, now I am facing issues that some programs I am calling that access files can't find them.
Case 1:
(Pls don't ask why it is so complicated, but the file structure is given and I can't change it)
I am calling a python script, that iself calls a batch file
filepath= os.path.abspath(os.path.join(pamFolder, "run.bat"))
p = subprocess.Popen(filepath, cwd=pamFolder, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
... and the batch file again a jar file with the actual program
java -XX:-UseGCOverheadLimit -cp "../..;../../libs/*" -jar ..\..\myjarfile.jar
Within the jar file there is an access to a file on the disk failing with an error message that the file can't be found:
ERR : The file was not found in the specified path 'U:\somefile.txt'. Please check this path for access and your configuration!
Case 2:
I am calling a batch file from Jenkins that is calling some other exe and in the end trying to open a file in Excel via the COM interface. Here I am getting the following exception (Excel can't access the file):
Unhandled Exception: System.Runtime.InteropServices.COMException: Microsoft Excel kann auf die Datei 'D:\Jenkins\workspace\myJob\someDir\someFile.xlsm' nicht zugreifen.
Question
As previously mentioned, both jobs were working in the previous setup. Both files DO exist.
I suspect that Jenkins / the programs are trying to find the files on the master where they are not available.
Is there any way to tell Jenkins that the called tools are fully executed on the slave node or in some other way tell them where to find these files?
EDIT
The job is already running on the slave. The console shows Running on [slave name] in D:/Jenkins/workspace/xxxxx.
The master is configured in a way that only jobs assigned to it run on the master. So pretty much all jobs should run on the slave.
EDIT2 / SOLUTION
It turned out that the 2 issues are caused by different things.
Case1: Solved this by using the UNC path
Case2: Solved by a mixture of giving the necessary permissions as described here and starting the slave service with a user with admin rights.
From my experience with this issue, usually it has to do with your SCM setup.
But as you stated that the files DO exist I think there might be the possibility that U:\ is a network share? Then consider changing your path to use a UNC path.
If that's not the case check if your jenkins slave as sufficient user rights to access said file.
You can tell Jenkins to run the job on the designated slave as follows:
Under Nodes > [SLAVE] > Configure, specify a label for the slave.
Under [Job] > Configure > Restrict where this project can be run, enter the label.
Now when you build, the console output of the job should read correctly along the lines Running on [SLAVE] (build_agent_01) in C:/jenkins and the files must be accessible.
(26.07.2016)I am using TFS2015 Update3 in a VM.
When I try to queue a build through the web interface or from Team Explorer, I get the following.
Then I restart all services related to TFS in services.msc and then after some time it starts working again.
So this happens too often.
I have a custom pool running:
Is there a way to debug this behaviour?
Examining the Log files
Link to Worker log file
Link to Agent log file
Exception occurs in this order here:
Checking if artifacts directory exists C:\workspaces\agent\_work\2\a
Deleting artifacts directory
System.ComponentModel.Win32Exception (0x80004005): The directory is not empty
at Microsoft.TeamFoundation.Common.FileSpec.DeleteDirectoryLongPath(String path, Boolean recursive, Boolean followJunctionPoints)
The weird thing is, queueing new build works most of the time, this happens only sporadically
It could be, that I have opened a file from that folder in notepad with many tabs open. Will observe if this issue persists and report.
If this is happening sporadically, it might a long path exists here in artifacts:
C:\workspaces\agent_work\2\a
Or, there was a cancelled build which left the artifact directory half cleaned which exposed a bug in cleaning.
The 2.x agent isn't subject to long paths (net core) but only works with 2017+:
https://github.com/Microsoft/vsts-agent
We can troubleshoot but it would be good to get to 2017+ (2018 QU3 is out) with a 2.x agent.
If that's not an option, message me and we can dig into what I think is a cancel / state bug.
I am having some serious grief trying to publish my mvc6 application due to a powershell file blockage. I ran powershell as an administrator and adjusted the execution policy. But it doesnt seem to have any impact on the publishing process in vs2015. Further to that i even tried in vain to run the Unblock-File cmdlet in the NPM.
Anyone have any ideas about how I can get this to work? the full error is below:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Microsoft.DNX.Publishing.targets(386,5): Error MSB4018: The "InvokePowerShell" task failed unexpectedly.
System.Management.Automation.PSSecurityException: AuthorizationManager check failed. ---> System.Management.Automation.Host.HostException: A command that prompts the user failed because the host program or the command type does not support user interaction. The host was attempting to request confirmation with the following message: Run only scripts that you trust. While scripts from the internet can be useful, this script can potentially harm your computer. If you trust this script, use the Unblock-File cmdlet to allow the script to run without this warning message. Do you want to run G:\_PIPELINE_MANAGEMENT\_SOURCE\_MANAGEMENT\_2016\ProjMgr\src\ProjMgr\Properties\PublishProfiles\ProjMgr-publish.ps1?
at System.Management.Automation.Internal.Host.InternalHostUserInterface.ThrowPromptNotInteractive(String promptMessage)
at System.Management.Automation.Internal.Host.InternalHostUserInterface.PromptForChoice(String caption, String message, Collection`1 choices, Int32 defaultChoice)
at Microsoft.PowerShell.PSAuthorizationManager.RemoteFilePrompt(String path, PSHost host)
at Microsoft.PowerShell.PSAuthorizationManager.CheckPolicy(ExternalScriptInfo script, PSHost host, Exception& reason)
at Microsoft.PowerShell.PSAuthorizationManager.ShouldRun(CommandInfo commandInfo, CommandOrigin origin, PSHost host, Exception& reason)
at System.Management.Automation.AuthorizationManager.ShouldRunInternal(CommandInfo commandInfo, CommandOrigin origin, PSHost host)
--- End of inner exception stack trace ---
at System.Management.Automation.Runspaces.AsyncResult.EndInvoke()
at System.Management.Automation.PowerShell.EndInvoke(IAsyncResult asyncResult)
at Microsoft.Web.Publishing.Tasks.InvokePowerShell.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
Done executing task "InvokePowerShell" -- FAILED.
Done building target "PowerShellPublish" in project "ProjMgr.xproj" -- FAILED.
Done building project "ProjMgr.xproj" -- FAILED.
Done executing task "MSBuild" -- FAILED.
Done building target "FileSystemPublish" in project "ProjMgr.xproj" -- FAILED.
Done building project "ProjMgr.xproj" -- FAILED.
2>Publish failed due to build errors. Check the error list for more details.
Create another publish profile and try again.
For me this works.
I managed to get it to publish by copying my entire project folder to the root of my local. Must be a folder permissions issue somewhere...
I've configured Release Management to pick up when source is checked in and deploy the code. However, I am having a problem:
System.Web.Services.Protocols.SoapException: Server was unable to process request. ---> System.Exception: Package location "\devserver1\Drop\Release Manager Build (Continuous)\Release Manager Build (Continuous)_20140115.15_PublishedWebsites\FrontEnd_Package" does not exists or Application Pool user does not have access. at Microsoft.TeamFoundation.Release.Common.Helpers.FileTransferer.CopyFolder(String sourceFolder, String destFolder) at Microsoft.TeamFoundation.Release.Services.DeploymentControllerService.GetPackageFileInfos(String packageLocation) --- End of inner exception stack trace ---
The strange thing is that if I simply open up Release Management tool, go to the failed deployment and click "retry deployment" it works first time no problem.
I have tried giving "Everyone", "TFSService" & "ReleaseManagement" users full permissions to both the drop folder and the build folder but still it doesn't work.
Please help!
So turns out that because I didn't have a "Configuration" set up in my build process, nothing was created as there was no default either. Once I created this it seemed to work.
My discussion with Microsoft here:
MSDN:Release Management - Continuous Integration
I had to give "Network Service" explicit permission to the drop folder.
I'm trying to get TFS to automatically publish (not package at the moment) my web app on a build to a Win2k3 server with IIS6. The remote agent service is started.
The build fails giving me a 401. I'm now trying to manually run a cmd line from the build server itself (just incase the MSBUILD was doing something strange with the params set on the build definition) and it's giving me the same thing. Here is the command I'm trying to run:
msdeploy.exe
-source:contentPath='C:\Builds\1\Test\DummyTFSWebApp Submission Build\Binaries\_PublishedWebsites\DummyTFSWebApp'
-dest:contentPath='Default Web Site',
computerName='http://ipm-vm-dev/MSDEPLOYAGENTSERVICE',
userName='Domain\AdminUser',
password='Password',
authType='basic',
includeAcls='False'
-verb:sync -allowuntrusted
But like the build report, it's giving me:
I can't understand why! The username & password provided is an Administrator on the destination machine. I've even made the build server machine and admin (clutching at straws), and I've made the destination folder a share for everyone with write permission.
Help appreciated as this is really frustrating me!
I changed the authType='NTLM' and it now works!
/p:AuthType=NTLM