I currently have an on-premises TFS 2017, a TFS build and a test that fails on the build agent but not when running locally. I heard about historical debugging but I couldn't find instructions on how to enable it on a TFS build, if that's even possible.
Is it possible to configure my build so that it generates an intellitrace file for me to debug the test run afterwards?
For intellitrace which related to the old testsettings file and could add some variables to configure this.
You could also manually enable such option in the VS on your build agent.
Also find a link mentioned it seems also work with Msbuild arguments. Even not documented anywhere in Msbuild command doc. I wonder whether IntelliTrace is still running even though it's not explicitly specified to do so
However, looks like you just want to find the root cause why your tests failed on tfs build even it passed locally.
To narrow down the issue, suggest you directly remote to your build agent. Instead of through TFS build, manually build your project, run the tests in the Visual Studio on build agent.
It will come out whether it's an environment issue. You must make sure it's the same environment for build agent and your local.
TFS is just using build service account to invoke msbuild/vstest command in build agent to run build/test.
Also make sure build service account have appropriately permission if your tests required some permission.
Related
I've recently started to encounter a problem with a new build agent that I have added to my TFS agent pool. The agent runs my build the first time without any problem. However, all subsequent builds fail with this error "##[error]The directory is not empty". This occurs on the initial startup of the build when it is trying to download files from TFS.
Keep in mind that I have set the "clean" option to true for the build and also set the Build.Clean variable to "all"
I've done searches online for this error and most of the info I am finding states that the directory is in-use and that is why it cannot be deleted. The strange thing is that I can manually delete the folder using Windows Explorer and there is no error reported of files in-use. Once I do that, the build will work again, but only on the first run. Why is it that the TFS vNext build cannot delete this folder? Is there a log that I reference that provides more details other than "directory is not empty"?
You could set system.debug=true to enable verbose Debug Mode for TFS vNext Build.
In addition, you could also check the agent log under agent path\_diag path here.
If there are more information for troubleshooting.
Back to your issue, please try to stop you build agent service and restart again. Also update your build agent to latest version.
Besides, you could also choose another driver such as D:\ or E:\ if you are using c:\agent\ which may do the trick.
I have installed TFS 2018 Community and was trying to publish a project to plesk domain using one of the publish profiles in the arguments of msdeploy task as shown in the picture below but it only build the project but did not publish it like I thought it would
Generally if you can run the msbuild command successfully with the arguments on local VS, then it should be also available in TFS.
So, please check below things to narrow down the issue:
Just make sure you have the same components installed and configured
on your build agent machine.
Make sure you have the correct configuration for your build
definition.
Based on your screenshot above, just try to set the correct buildPlatform and buildConfiguration (consistent with your project settings in VS).
Also verify that if you have checked in the PublishProfiles, and check the first Get sources step, make sure the system can get the sources and PublishProfiles during the build process.
This article for your reference : TFS 2015: deploy website to IIS without installing extra add-ons to TFS
UPDATE:
In order to use Publish Profiles on the build server, you have to have some of Visual Studio's prerequisites. Make sure you have installed the full version of Visual Studio on the build agent machine.
Besides, you can try with below arguments (Just change the PackageLocation value accordingly) :
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\"
Referecne: Working with Web Deploy and Release Management for the deployment.
I have a TFS 2017 Update 2 on-prem server with VS 2017 Enterprise installed. Our Build contains a Unit-Testing project which contains a Fakes assembly and works locally on the dev machines.
When build on TFS, the build fails with
The type or namespace name 'Fakes' does not exist in the namespace
'Our.Product' (are you missing an assembly reference?)
(i.e. misses/fails to generate the Our.Product.Assembly.Fakes.dll file)
I have additionally set up Fakes as suggested here.
What baffles me is that there are no mentions of Fakes in the build log (except for the error itself and the paths where MSBuild looks for the file), even with debug verbosity. He doesn't event try to generate the Fakes assembly.
Are there other steps I need to take? We use the vNext build definitions.
Update:
This is the build step that works now, before the /tv:15.0 /p:VisualStudioVersion=15.0 were not there.
Update
Use the latest version for msbuild arguments such as /tv:15.0 /p:VisualStudioVersion=15.0 could solve this issue.
First try to use build service account RDP to remote build agent and manually run the build to see if the assembly generated.
This will narrow down if it's related to your environment on the build agent. Make sure it's the same as your locally dev machines.
If the assembly is also generated, then the issue may related to your build definition settings. Check if you are using the right msbuild version. For vNext build, also enable verbose Debug Mode with system.debug=true
Our plan is to use Team Foundation Build service to do automatic builds, then use the testing facility to automatically perform testing on the build server then release that build onto the application server.
So far we have
Team Foundation Server with TF Build Controller configured
Build server with win2012, Visual Studio 2013 and Build agent configured.
SQL Server with SQL 2013 installed
Application Server with Win2012 and .netframework installed
My question is what do I need to do to set up automatic builds, and to execute the unit test harness once compilation is successful.
Also the deployment target machine will initially be DEV, however we would like to quickly build for test env and prod etc.
This is what I got so far.
Build Controller (Already set up I believe)
Build Agent (Already installed on build server)
Build Process Template (Do I need to do anything with this. Is this what controls the whole lot)
Team Build Definition (I had a look at this, and it seems to use the build process template)
Drop Folder (I am assuming this is where the executables will be dropped into).
At the moment I have bits and pieces of info, what I would like to know is how this whole thing is hanging together. From the moment the developer wants to do the build to the moment that exe is placed into the DEVAPPSERV (Development application server).
Is anyone able to point me in the right direction or give a summary of what I need to make this happen?
Many thanks,
Dalibor
Install TFS Server (TFS Disk) Create a Team Project Collection and any desired Projects
Install TFS Controller + Agents onto a dedicated machine (TFS Disk) Configure only the build options if on a different machine to the TFS Server
Configure Build Controller to connect to a Specific Team Collection on your TFS Server
Install VS Premium or higher on build machine, if you want code coverage results for your tests
Add some code to TFS Source Control
Create a Build Definition using the default template.
Configure the build definition.
Set the working folder for the build, include only what you need as this will speed up the process
Point the definition to your .sln or proj file.
Ensure testing is enabled and that your test assembly names will match the regex used to identify test dll's i.e. name your test assemblies with the word test.
Set the trigger to be CI or what ever flavour of build you require i.e. gated build
Save the build definition
Trigger a manual build and debug any issues
you should have the basics done and a repeatable build created.
That should cover the basics, you may want to customise the build template (see Ewald Hoffman's guide for tips), you may want to narrow down your code coverage (look for runsettings file info).
If you follow these steps you should be able to get a basic build created and running from these, if you hit any issues you can come back and ask specific questions about a particular area
In order to do automatic builds you should check the CI build option ( under the trigger build option ) and third party automated testing can be run by executed by a post build script.
See the following TFS article about post build scripts.
http://msdn.microsoft.com/en-us/library/dn376353.aspx
My Question: How can I run a deployment script from the TFS 2010 build template on a remote system that has only a MSTest agent running?
I know this can be done by activating the Deployment section in the test settings configuration file, but this is not flexible enough. At night a build runs. When the build is successful, a deployment script is placed at a drop location. The drop location is date, project and build definition specific. These parameters are available in the TFS build template we use.
I do not have Lab Management available, just a physical server. I would rather not spoil the physical server with an additional build agent to only do the deployment. The MSTest agent is apparently capable of running deployment scripts, but how do I use that functionality from the TFS build workflow. For example, can I use the RunDeploymentScript activity without having Lab Management?
PSExec is a great tool for running scripts on remote computers. I use this in Team Deploy that allows you to install MSIs on remote computers from Team Build. You can also run PowerShell on remote computers but it is a little more complicated to set up. Another option is to use MSDeploy. There is a command option that you can run any command on a remote computer. I usually use an InvokeProcess activity to call a PowerShell script on the build server. From the PowerShell script I have called MSDeploy to run a remote PowerShell script on a target server. It sounds bad but worked good.
You can't run the RunDeploymentScript on the target machine. You can use a modified template to deploy to a physical environemnt. Here is a good post on doing this.. The options I mentioned above do not need any agent on it. You can use the ExecuteRemoteTestRun lab management activity without Lab Management to run the MTM Tests with the Test Agent with a Test Controller that is registered to the project collection (Test Manager).
Let me know if you have any questions on any of these options.