In TFS 2012, I was able to use XAML based on this to customise our workflow to compare the number of warnings in the current build, to previous builds. (I have seen similar code elsewhere to check that code coverage has not gone down, etc).
In TFS 2013, there appears to be no way to retrieve results from previous builds as the BuildDetail type is no longer visible. Specifically, I got the following error:
The build process failed validation. Details: Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "Microsoft.TeamFoundation.Build.Client.InformationNodeConverters.GetBuildWarnings(BuildDetail).Count". 'Microsoft.TeamFoundation.Build.Client.BuildDetail' is not accessible in this context because it is 'Friend'. Validation Error: The private implementation of activity '1: DynamicActivity' has the following validation error: Compiler error(s) encountered processing expression "BuildDetail.BuildServer.GetBuild(BuildDetail.BuildDefinition.LastGoodBuildUri)". 'Microsoft.TeamFoundation.Build.Client.BuildDetail' is not accessible in this context because it is 'Friend'. 'Microsoft.TeamFoundation.Build.Client.BuildDetail' is not accessible in this context because it is 'Friend'.
Is there any way, in TFS 2013, to access details of previous builds, that BuildDetail.BuildServer.GetBuild provided in TFS 2012? I cannot find any samples on the web that aren't using the old method.
The TFS Product Team have dramatically simplified the build as 90% of people out there either do not customise or want some simple customisation that can be done in PowerShell. If you want to have BuildDetail you can get it by using the "GetBuildDetail" activity that is included in the build.
After further investigation, it turns out that the TFS Build Extensions provide a GetLastGoodBuild activity, which appears to do what I need.
Related
I've tried to get this to work a few times but running into the same problem.
A number of workitems are failing with the following error:
OH-Connector-0143: Target system does not contain value : Resolved for field: State for entityType: Task
I've replaced the source projects WIT with the standard versions and I've tried to change the status on the work items referred to. All are Task type work items and have had state set to Resolved at some point although I have checked all failed items and none currently set to that state.
We are also seeing another failure message which I have assumed is caused by the above error which is:
OpsHub-012010: Processing blocked - earlier event(s) for entity 6960 have to be processed first.
Additionally, no source has migrated. It is my assumption that this is because of the work item failures?
The reason the failure is because the history of those workitems has already been persisted. It cannot be changed. You can update the current value of those WITs with an available state, but the historic revisions will remain the same.
OpsHub's Migration Tool migrates your entire history. Therefore, while processing the revisions where the State was 'Resolved', the issue is encountered.
And yes, the 'processing blocked' errors are because of the above error and the SCM migration will not start until the WIT is done due to linkage dependency.
To prevent unexpected build breaks and test failures, We have been using gated check ins. This works very well for our core solutions, and has helped improve our quality.
As part of our overall architecture, we have a certain section of our code with many micro-services, each of which is a new solution. New solutions are added to this part of the code base regularly. These are important parts of the system, and I need to make sure they get compiled as part of a gated check in without the chance for developer error.
Is there a way to configure TFS to find ALL solutions under a certain path and include them in a gated check in build?
Thanks
Not without modifying the build process template, which is almost never a good idea. The new build system in TFS2015 does allow that, however.
TFS 2015 vNext builds allow wild cards to search for all solutions. I haven't had success getting this to work with Visual Studio build steps, which you would need, but it works well with NuGet Installer and other build steps. We will not see gated builds in vNext builds until we get update 2 see TFS feature timeline
I am getting the following error when running my build on Visual Studio Online (using the built-in Build Controller):
C:\Program Files
(x86)\MSBuild\14.0\bin\amd64\Microsoft.Common.CurrentVersion.targets
(3962): Could not copy
"d:\a\src\MySolution\MyProject\Trunk\packages\Microsoft.Data.Edm.5.6.4\lib\net40\Microsoft.Data.Edm.xml"
to "..\Build\bin\Release\Microsoft.Data.Edm.xml". Beginning retry 1 in
1000ms. The process cannot access the file
'..\Build\bin\Release\Microsoft.Data.Edm.xml' because it is being used
by another process.
It is never the same file either but it seems to always be either an xml or dll from the packages folder.
EDIT: I'm not sure if it is worth mentioning, but I do have multiple workspaces and multiple build definitions using this repository.
I found the problem. Completely unrelated to the error above.
I went into the msbuild log files and found this:
Failed to produce diagnostics extension's config for
MyRole\diagnostics.wadcfgx. Error : Could not find a part of the path
'd:\a\src...\MyRole\diagnostics.wadcfgx'. Done Building Project
"d:\a\src...\MyCloudProject.Cloud.ccproj" (Publish target(s)) --
FAILED.
I was missing a file in source control.
I do wonder why this error did not bubble up into my build summary. And where did that initial error come from?
I am using TFS with Using Visual Studio 2013 and have been able to work around this issue by closing all open documents that I want to check-in (seems VS locked itself out) and/or resolving conflicts. The error message is sufficiently vague so as to be useless as to the actual cause of the check-in failure.
Update 02 November 2016:
I'm not sure why VS 2013 and TFS don't play nice together via the Team Explorer Check-in Pending Changes button, but it consistently fails to launch the conflict resolver, a key piece of the check-in process.
The following works for me on VS 2013 and TFS hosted on a SQLServer Express 2014 database:
1. Launch the Source Explorer: Team Explorer tab -> Source Explorer
2. Navigate to your solution repository
3. Then proceed to do the following for each project that you want to check in:
a. Right click project
b. Check in pending changes
c. Resolve conflicts and repeat steps 3a and 3b until no pending changes remain for the project
We're using Visual Studio Online, but we have local Build Controller and Build agent. This has been running fine for the past 6 months or so, but just this week the builds have consistently failed.
The software itself appears to build successfully, and the tests also seem to pass, but it fails due to an error during the publication of the log files (see error below).
The build uses an unmodified Default Template, and is setup so that it "does not copy output files to a drop folder" (in the Build Defaults of the build definition).
After a few hours of head-banging this feels like some sort of permissions thing, but I have no idea how to go about debugging, or verifying this assumption.
Can anyone offer any suggestions, or better yet, a solution! :-)
One other thing to note is that we have been mucking about with our users in Visual Studio Online to change some accounts from Basic to Stakeholder accounts in order to reduce costs. I'm wondering if we've also managed to remove a critical account or permission that has caused this...?
Error
An error occurred while copying diagnostic activity logs to the drop location.
Details: TF270002:
An error occurred copying files from
'C:\Users\tfs\AppData\Local\Temp\BuildAgent\5498\Logs\2853\LogsToCopy\ActivityLog.AgentScope.5498.xml'
to
'ActivityLog.AgentScope.5498.xml'.
Details: BadRequest: Bad Request
An error occurred while copying diagnostic activity logs to the drop location.
Details: TF270002:
An error occurred copying files from
'C:\Users\tfs\AppData\Local\Temp\BuildController\4592\Logs\2853\LogsToCopy\ActivityLog.xml'
to
'ActivityLog.xml'.
Details: BadRequest: Bad Request
Edit
One thing to note is that this error is consistent across all builds for different C# projects that are executed through the same build controller. I've tried removing and re-registering the controller, restarting the build service and the build server itself.
we are also experiencing similar issue. We have not done any changes to VSO permissions, so I doubt it is that.
Two things that coinside this:
1. There was an update to VSOnline during the same timewindow that this issue appeared
2. Our local build controllers/agents were updated with latest Patch Tuesday updates
So the solution to this (in my case anyway) was to upgrade the Build controller software to v12 (TFS 2013).
I'm creating a custom build process template that allows the person who is queueing the build to define the build and revision numbers (as they are used on the assembly version info).
However, if the build fails, they can't queue a new build for the same version (but they should be able).
Is there a way to automatically discard the build if any step in the workflow or MSBuild Script fails?
TFS maintains assigned build numbers in the database itself, for its own administrative purposes. This maintains its internal consistency with all the assets that are produced and (intermediate) work products.
The only way to free up a previously used build number is to actively DESTROY it from the database. Please see http://geekswithblogs.net/jehan/archive/2011/04/23/tf42064-the-build-number-already-exists-for-build-definition-error.aspx for a further explaination.
One of the features added in TFS 2012 is the ability to retry a build.
This allows you to right click a failed build and select retry instead of queuing a new build. This should allow you to run a build with the same configuration settings without getting errors on your build numbers.