In Build page in Team Explorer, we have a list of build definition and when select them all, the delete command is disabled.
Selecting only one enable us to delete it.
Is there other places where we can quickly clear all the build definition?
To Deletion of the build, The documentation is here have a look for deletion
http://msdn.microsoft.com/en-us/library/gg475877(v=vs.100).aspx#deletebuild
just goto "To delete a completed build" this section and read
Updated: (I thought you were asking for build deletion)
Here I found a tool called Team Project Manager, It allows you to automates various tasks as they mentioned. you can try this
http://teamprojectmanager.codeplex.com/
There is a free tool called the Community TFS Build Manager that allows bulk operations on Build Definitions (including Delete). You can find the 2013 version here: http://visualstudiogallery.msdn.microsoft.com/73bf2d8e-aec6-406c-8e7f-1c678e46557f
Related
We have a project which cannot be removed completely. We use TFS API output all the projects and their size and we find a project which we cannot see it on the web or VS. The project is very big(more than 200G). We try to delete it, but met some problems. I tried to remove it with the command "TFSDeleteproject ..." and got the error message as bellow.
"The team project could not be deleted. Either the delete operation failed, or project creation failed but partially-created project could not be deleted. Review the previous entries in this log for details. The team project has been taken offline and remains in a non-operational state. It is not accessible to Team Explorer. To complete the deletion, address the errors noted in this log, and then attempt deleting the project again."
Is there any other way to remove the project? Any advice is welcomed.
Thanks,
I think You read Delete a team project with TFSDeleteProjec guide.
There is even a description on how to Verify Project Deletion.
In addition I think main space occupation can be related on version control files, if this is Your case you can use TFS Destroy command to destroy, or permanently delete, version-controlled files from Team Foundation version control and related changeset history.
If you not like command line, I suggest to use TFS Source Control Explorer Extensionthat integrate destroy in source control advanced right click menu.
I know DefaultTemplate.xaml does everything needed. But I gonna learn team build this by creating an entire new build process from scratch. I need to know which activities must be included, in which order and so on. This must be using WF in Team Build 2010.
Many Thanks in Advance
UPDATE:
I found this link in MSDN that describes build definitions completely, but does not contain anything about Microsoft.TeamFoundation.Build.Workflow.Activities namespace.
UPDATE 2:
I found a similar question in the MSDN Forums.
UPDATE 3:
Found a link titled "Customize Team Build 2010". But this does not help more too.
Take a look at the upgrade template. If you remove the MSBuild activity, you're fairly close to a minimal build workflow that still supports gated check-ins, etc.
I've seen the question related to the error message you get from TFS when a workspace is already mapped. The accepted answer for removing the workspace is alright as a workaround, but it's already getting tedious to run a delete command each time this error occurs.
What do I need to change in order to get out of having to use this workaround? I've got two builds (continuous integration and nightly deploy), and need to add at least one more build type. I followed this URL to see if there was a possible resolution there, but I'm not sure I understand it completely.
I am not sure how this is accomplished in TFS 2010, as I have not gotten to work with Team Build in 2010, yet. In 2008, though, if you expand the Builds node in the Team Project and right-right click on either of the builds, you will see a "Manage Build Agents..." option. Click into that, and it will bring up a dialog. One of the things on that dialog is an option called "Working Directory". Do you have the same hard-coded path in both of them?
By default, when you create a new build definition, it provides a calculated folder for this value. This is where the build agent will do the checkout from TFS for the build attempt. The default value is, $(Temp)\$(BuildDefinitionPath), I believe (I am not connected to TFS at the moment).
The article you link to is basically saying that you should include either that $(BuildDefinitionPath) value or the $(BuildDefinitionID) value as part of that path in that dialog so that the two builds do not try to use the same workspace. Changing the working folder to include one of those values should resolve your issue, going forward.
Does TFS offer a way to save, track, and later redeploy builds by build number, or can you only deploy .dlls compiled from the current codebase? I'm looking for functionality similar to what you find in Changeman DS.
Yes. Every build definition in Team Build has a "retention policy" that defines how many historical builds should be kept, depending on certain criteria. You can also mark individual builds as "keep indefinitely." Kind of like a Tivo...
Example walkthru with screenshots: http://blogs.msdn.com/buckh/archive/2007/08/14/tfs-2008-a-basic-guide-to-team-build-2008.aspx
If you need to recover a build that has already been deleted from the drop share, you can do that too -- you'll just have to rebuild it. Simply queue up the build definition, but before you hit Go, type /p:GetVersion="XXX" in the text area at the bottom labeled "additional MSBuild arguments." XXX can be any versionspec, just like you'd use at the tf.exe command line. Examples might be "C12345" or "D1/10/2010" or "LsomeLabel".
I have a Team Foundation Server 2008 Installation and a separate machine with the Team Build service.
I can create team builds and trigger them manually in Visual Studio or via the command line (where they complete successfully). However check ins to the source tree do not cause a build to trigger despite the option to build every check in being ticked on the build definition. Update: To be clear I had a fully working build definition with the CI option enabled.
The source tree is configured is a pretty straight forward manner with code either under a Main folder or under a Branch\branchName folder. Each branch of code (including main) has a standard Team Build definition relating to the solution file contained within. The only thing that is slightly changed from default settings is that the build server working folder; i.e. for main this is Server:"$\main" Local:"c:\build\main" due to path length.
The only thing I've been able to guess at (possible red herring) is that there might be some oddity with the developer workspaces. Currently each developer maps Server:"$\" to local:"c:\tfs\" so that there is only one workspace for all branches. This is mainly to avoid re-mapping problems that some of the developers had previously gotten themselves into. But I can't see how this would affect CI.
UPDATE: Ifound the answer indirectly; please read below
Ok I have found the answer myself after several dead ends. In the end I fixed this unintentionally while fixing another issue. Basically we had just turned on the automatic execution of unit tests for our builds. The test would run sucessfully but then immediately the build would bomb out with a message saying it was unable to report to the build drop folder.
What was happening was that while the Build service runs under one account and has a set of rights; some of the functionality is actually driven through the TFSService account. fter wading a heap of permissions I had my tests being reported. Then I noticed that builds had started to trigger on check-ins; I can't tell you exactly which permission fixed this but hopefully this answer will at least set people down the right path.
One other note a few of the builds started failing due to conflicting workspace mappings - this was a separate issue that I resolved by deleting some obsolete workspaces using the Attrice Sidekicks for Team Foundation tool.
Hope this helps somebody else.
Select your team project from team explorer, then right click on the Builds folder. Select a new build definition and then select the trigger tab. Move the radio button to "Build each check-in (more builds)"
More info can be found here
MSDN How to: Create a Build Definition
Are there any errors in the log on the TFS application server? Anything that indicates that it tried to fire but failed?