Is it possible to use Team Foundation Build Services to put the lastest Build of a Build Definition to a fixed UNC File Path.
Normaly the Build Definition adds some Variables like Date or Build Number into the Path to make it unique.
I tried to delete them in my Definition to get a fixed path, but the Build failed with the Error that the Destination already exists on the Server.
Why do I want to Build to a fixed location:
I want to do that so the Team testing my Application has a fixed location to the latest Build, and can e.g. put a Shortcut on it.
The best practice is to have fixed drop location as root folder with Build number added to the path. This would help you to distinguish different build versions executed from a build definition. If you have fixed location, then what would you do if you want to get previously executed build binaries in case if latest build breaks?
If you still want to go with fixed location, then you could modify the build process template to delete the fixed folder during the build process so that you wont get destination already exist errors.
Related
I'm trying to run some unit tests using Final Builder Continua but nothing I try seems to work. I've configured a Unit test stage:
But everytime I run the build I get the error:
The expression ['$Agent.NUnit.3.0.Path$' exists] evaluated False
then the whole thing hangs. There are several issues reported on the final builder forums but the soliutions all relate to older versions or various other fixes none of which seem to apply to my situation.
I'm guessing it doesn't know where the NUnit console is. I have tried specifying the missing parameter in the build config for the agent:
I've tried installing NUnit from nuget
nuget install nunit
Has anyone any experince of this or solutions to this issue?
I'm using continua 1.8.1.277
It's not practical for Continua CI to know all possible installation locations for NUnit. If installed using NuGet then it will be installed under the current directory by default - this installation folder can be changed using the OutputDirectory parameter for NuGet.
Editing the property collector search path is not considered to be a hack - it is actually a recommended solution if you know the path of the executable.
Another equally valid solution would be to add the path to the executable to the PATH environment variable on your agent. As of v1.8.1.556, Continua CI will automatically pick up changes to the PATH variable without restarting agent service.
Note that the NUnit action also provides a option to install the executable using NuGet as part of the build:
Ticking the "Install NUnit on agent using NuGet" will show a NuGet tab allowing you to enter the NuGet install parameters.
You can also choose "Custom" in the Using drop-down. This allows you to specify the path to the executable to use for this action.
Simply by clicking in random places I noticed this under Property Collectors (No I don't know what this actually means):
This seems to suggest that it will look in certain folders for Nunit (not where nuget installs them interestingly):
Finds the executable 'nunit3-console.exe' in any of the following
locations '%PROGRAMFILES%\NUnit.org\nunit-console\,
%PROGRAMFILES(x86)%\NUnit.org\nunit-console\, %PATH%'.
So I created a new folder in my program files and copies the required nunit3-console.exe etc. into it. I now no longer get the error.
Seems that edit allows your to (ahem) edit these paths. So a better solution is to add the path to NUnit into this variable:
So I have reviewed the link to solve this problem, as referenced below.
Team build error: the path already mapped to workspace
But my problem is that EVERY time i queue that Build Definition i get the same problem. Ok, i go delete the tfs workspace it's complaining about. Great it works! Then run the build again... ok now it doesn't and i have to go delete the TFS service workspace all over again.
How come TFS build service is stepping on itself every time it does a build. The error is " Unable to create the workspace 'xxx' due to mapping conflict... the path xxx is already mapped in workspace 'xxx'" but the mapping is to a workspace that the previous BUILD created. Not anything from a specific user.
ok, this seemed to occur because (i hadn't noticed) that i changed the "Build Agent Folder" specification by accident to a fixed path. rather than keeping it with $(SourceDir). I changed the entry in the build definition to this and it worked fine, after multiple builds using same build definition.
On some host, when using nuget.exe restore solution.sln
to force package restoration before build, I observe that command does not behave in identicall way compare to Nuget visual plugin.
On some host the command version append the build number (default value 0) to the version number,
causing the path in package folder to contain that build number.
So for example instead of having:
/packages/my_package.1.57.0/...
I have instead :
/packages/my_package.1.57.0.0/...
In the end it cause the build to fail, because internally,
target that are stored inside the .vcxproj are looking for the first path that do not contain the build number.
I don't know if it's relevant to the observered behavior, but those package are native C++ package build using CoApp
If instead of using nuget.exe on the same host, I am using the package manager restore functionnality from visual 2013, it works wells, and package are properly copied with path that don't include the build number.
And then build is ok.
As nuget.exe work on some host and not on some other, I am suspecting either a different version of a component or a different default setting.
For the component I have checked:
nuget version: 2.8.50926.602
visual 2013 version: 12.0.31101.00 Update 4
And they are identical on both host that work and that don't.
So what's left ?
Finally it end up to the following simple scenario (unfortunately I cannot reproduce the issue):
package in trouble where homemade package of boost library.
some of these package may have been available with the same name, but
different content and version numbering on nuget.org
On a workstation having the issue I was able to solve it by:
disabling nuget.org from the list of repos
and most importantly => CLEARING the nuget cache !
Even if I was not able to reproduce : I am quite confident about this scenario, because when looking inside the package I saw that the content was different from the one I had built. So this package have been downloaded from elsewhere.
Following on from my previous question ( Watin does not work on my TFS build machine ), I have made my TFS build an interactive process.
I do however, get the following error when I run the build:
The working folder d:\Build\Sources is already in use by the workspace 8_1_appsdev_build;myUserAccount$ on computer myComputerName.
After some research, it seems that I need to delete my workspaces. If tried to list my workspaces with the following command, but the results indicate that I do not have any workspaces. Not sure what I am missing. Any ideas?
View workspaces command:
tf workspaces /computer: myComputerName /owner:*
No workspace matching *;* on computer myComputerName found in Team
Foundation Server http://myComputerName:8080/tfs/production.
Thanks!
You can find and delete the workspace by opening Visual Studio on build servers with same account or by using workspace sidekicks from TFS Sidekicks tool.
You don't necessary have to delete the workspace, something apparently going wrong here.
The message is just telling you that you attempt to create a new workspace with a mapping that is already used by another workspace.
For instance:
WorkspaceA already exists, it has one mapping: $\ to c:\pipo
Any attempt to create a WorkspaceB with a mapping that use c:\pipo (or a subfolder) will failed.
Maybe you create a previous Build Definition that use the same local path as the one you're trying to run: this will fail the same way.
To sum up there's per default one Workspace per Build Definition with the ability to make it persistent or not (mainly for speed optimization during the get of files), make sure two build definition don't use the same path in local.
tf workspaces looks at the workspace cache file to provide output. If you're running tf as yourself, you will only see workspaces that you have connected to. Thus, you would not see the build user's workspaces (regardless of the /owner option, which simply acts as a filter.)
Either run tf workspaces as the build user, or use the /collection argument to force a query of the workspaces on the server, bypassing the cache.
Within my teambuild we use custom build process activities, which are deployed at
\BuildProcessTemplates\CustomAssemblies\MyActivities.dll
The build controller is configured to load the assemblies from that path.
If I checkin new assemblies, then the teambuild does not load the new assemblies automatically, but uses the old ones. In fact the latest build process template seems to be used, because I get the error:
"TF215097: An error occurred while initializing a build for build definition <myTemplate> Cannot create unknown type <any new type>"
If I restart the build controller services, then the latest assemblies are considered.
How can I get teambuild to load automatically the latest assemblies, without being forced to restart the controller?
Finally figured this out. Been driving me nuts for months. Even if your binaries are technically different (i.e. binary differences), it looks like agents only get refreshed if the file version is different.
So more specifically, in my version of "MyActivities.dll", I had to increment the following two lines in my AssemblyInfo.cs (old version string was 1.0.0.0):
[assembly: AssemblyVersion("1.0.0.1")]
[assembly: AssemblyFileVersion("1.0.0.1")]
Once I did that, I did a normal build of the assembly, then checked in the new binaries. Agents were refreshed with the new versions within minutes! :D
Other (less awesome) options if you can't update the version for some reason:
Check in a dummy file to the same dir. If any files are added/removed from the CustomAssemblies dir, it forces a refresh for all files
Change the "Version control path to custom assemblies:" value to some dummy value (doesn't matter where), apply the new value, then change back to the original directory. Any time the path changes, that forces a refresh for all files
The "Best" solution is to just update the file/assembly version, though.
Try to install MyActivities.dll into the GAC. I have all my custom assemblies in GAC and I didn't noticed any issues.