We use a few tweaked Build Process Template, developed for TFS2010 for all of our builds, but these BPTs are not using any custom activities. We recently upgraded to TFS2012, and during the upgrade converted our BPTs according to these instructions.
This works fine, most of the time, but periodically, it coughs up:
TF215097: An error occurred while initializing a build for build definition \Project1 (Dev10)\Simple - Manual: The values provided for the root activity's arguments did not satisfy the root activity's requirements:
'DynamicActivity': Expected an input parameter value of type 'Microsoft.TeamFoundation.Build.Workflow.Activities.BuildSettings' for parameter named 'BuildSettings'.
There's nothing in any log, there's nothing visible that I can see as the root cause in any way. The only fix is to restart the Build Controller, at which time the error vanishes for a few hours. When I unregistered and re-registered the Controller, the problem went away for about a day.
The important thing here is that these build process templates do work on TFS2012, but then they suddenly stop working for no reason I can determine.
As it turns out, some builds were still using legacy 2010-style Build Process Templates. Any time someone queued one of those builds, the entire build controller started freaking out. By getting rid of those BPTs, we resolved the issue.
Related
I am trying to integrate Gulp in TFS builds and web deploy using the article given here as reference. When I build the solution using the command (Alt+B+R), an output directory gets successfully created by gulp. But, when I try to queue a new build by right-clicking my build definition, the build fails with the following error.
Can anyone help to get rid of this error?
According to the error TF42097: A work item could not be saved due to a filed error.
The build uses the Default Template (or a customization) and has the Create Work Item on Failure option turned on, however the Bug work item has been modified in a way that means the build is unable to create it – which could be as simple as making a field mandatory.
How you fix this depends on how the Bug work item has been restricted. Work item fields that have been made mandatory should have a value specified in the build process template, and if that value should vary depending on the build definition you will need to expose it as an argument in the definition.
A workaround for this situation:
Adding in a PropertyGroup <SkipWorkItemCreation>true</SkipWorkItemCreation> will stop it from attempting to create the work item.
A similar question from MSDN for you reference.
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).
Introduction
I have a problem with Team Foundation Server Express 2013 on my machine. I have two build definitions on the same controller and agent, both of which run on the same server and the same environment as well.
It should be noted that I already looked at the "similar questions" without any luck. This is clearly not related to the same root cause, and the symptoms are slightly different too.
One of them is a gated check-in build definition, which just compiles everything when commiting to the development branch.
Another is a scheduled build definition, which runs every saturday at 3 AM, building any changes that may have been committed to the main branch since last time.
The gated build definition has a process (which only has minor changes for not running tests and just compiling the code) based on the TfvcTemplate.12.xaml template.
The scheduled build definition process is based on some Azure build definition template that might come from an older version of Visual Studio, possibly based on some Azure template, or maybe the TfvcContinuousDeployment.12.xaml template.
The issue
My gated build definition runs just as expected, without issues. It compiles the full solution, and only passes if the compilation succeeds.
The shceduled build definition however fails compiling (even before it reaches the point where it runs the unit tests). The error I see is as follows.
Obviously this is due to missing fakes assemblies. I tried taking the assemblies and checking them in (which I would rather avoid), only to find that this build definition runs just fine, but not the gated one which ran just fine before.
I thought about just running fakes.exe in the build template to just generate them manually before compiling, but in my initial tests (to see if this theory would even work), it won't even run in the commandline, and outputs some errors and warnings that I don't understand (but are probably not relevant anyway, since I might be running fakes.exe with improper arguments).
Updates
Update #1
It should be noted that I have Visual Studio 2013 Ultimate installed on my build server as well. Both this (and TFS 2013 Express) have Update 3 installed, and the server is fully updated.
I ended up abandoning fakes all together, and implementing Moq instead. Works a lot better, and forces me to abandon shims or moles, which are often considered bad practise anyway.
I have setup a build controller etc and the builds were failing, I have fixed these now and the build failed properly - as in because of an error.
I have fixed the error and checked the code back in but now the code is not being extracted, although sometimes one folder of many is.
I have deleted the code from the build machine and requeued a build but it keeps failing. It complains that it cannot find the solution that I specified as the build solution.
I have checked the check box to build even if nothing has changed.
Have I missed a setting somewhere for extracting the code?
TFS version is 2012 Express
Visual Studio version is 2010 Professional
I had this issue recently with TFS 2012. I think it boils down to this:
In the lastest build definition files, it appears that it performs a Clean task before updating the workspace. This means that if you do something that causes the Clean part of the build to fail, it will never download the new files in order to fix it.
Recently, I was making big changes to my build file and inevitably made a lot of mistakes, I found that if one of these mistakes caused the Clean to break, I had to go onto the Build server and change the file manually to get it working again.
Does this sound like it might be the same issue?
There are several properties in your build definition you can check. I would start with setting the "Clean Workspace" to All to ensure the correct code is being pulled down and built.
There are other checks you can look at as well like the agent set for the build and the "GetVersion" property. Check the below link out. It should be able to help you in more detail.
Define a Build Process that is Based on the Default Template
I have a vcproj file that includes a simple pre-build event along the lines of:
Helpertask.exe $(ProjectDir)
This works fine on developer PCs, but when the solution is built on our TFS 2008 build server under MSBuild, $(ProjectDir) is either blank or points to an unrelated folder on the server!
So far the best workaround I have managed is to hard code the developer and server paths instead:
if exist C:\DeveloperCode\MyProject HelperTask.exe C:\DeveloperCode\MyProject
if exist D:\BuildServerCode\MyProject HelperTask.exe D:\BuildServerCode\MyProject
This hack works in post-build steps but it doesn't work for a pre-build step (the Pre-build task now does nothing at all under MSBuild!)
Do you have any ideas for a fix or workaround? I have very little hair left!
$(MSBuildProjectDirectory) worked for me
I think your problem may be related to how items are initalized. An items include attribute is evaluated at the begining of a build. So if you depend on files that are created in the build process you must declare these as dynamic items. Dynamic items are those defined inside of a target, or by using the CreateItem task. I've detailed this on my blog MSBuild: Item and Property Evaluation.
Sayed Ibrahim Hashimi
My Book: Inside the Microsoft Build Engine : Using MSBuild and Team Foundation Build
I think the problem is that build server's workspace probably isn't initialized properly.
I just kept getting problems with this - I tried many different approaches but they all failed in mysterious ways.
Once $(ProjectDir) started behaving properly again, the pre-build step stopped executing the command (I added echo commands above and below it - they were both executed, but the program in between them was not. No errors or output of any kind were generated to indicate why it failed).
I don't know if this is a dodgy server of if MSBuild is having a laugh.
I've given up now. I gave the build server a big kick and have changed tack: We now run this tool offline (manually) and check in the results for the build server to use. So much for an automated build :-( If only MSBuild would run solutions in the same way as Visual Studio does - it's maddening that it sets up the environment completely differently (different paths coming out of the solution variables, ouptus redirected into different folders so you can't find them where they're supposed to be, etc)
I branched an existing project and $(ProjectDir) kept the old directory in the newly branched code. But that's because I had some compiling errors. Once every project in the solution compiled without errors, $(ProjectDir) changed to the correct path.
Carlos A Merighe