How can I setup an automated TFS build which would fire up only when check-in occurs in a specific branch of the project as opposed to on every single check-in across the team project?
In the Team Explorer there should be a folder "Builds" for your team project.
Right click, then choose "New build definition" from the context menu.
Set the trigger to whatever you like, e.g. gated checkin.
On the "Workspace" tab you can now choose for which workspace the build applies. Here you can choose the server path of a specific branch. Set this to the server path(s) you want the build to trigger on.
On the process tab you can choose which solution to build.
Hope that helps.
Related
I have two build definition "A" and "B". I marked "A" to be triggered (Gated Check-in) when the check in include files under "src\ProjectA" and "B" to be triggered when the check in include files under "src\ProjectB".
It's working as expected when the chech-in include only one of the folders.
When the check-in include both of the folder and I click the CkeckIn button in Visual Studio I have to select which build I want to run (I choose "A") and only this build running and all the files are getting in, meaning that some code get into the repository that can break the build that didn't run ("B").
How can I make TFS run both builds whenever such a checkin will be delivered and not accept the change if all of the depended build get passed?
Each gated check-in build definition can have only one running build at a time. If you have two build definitions configured for the same source control folder then you will always get a choice. Your situation is very likely configured for the same source control folder.
It is recommended to have only check in each Project fold instead of check in include both of the folder together to avoid confusion. As a workaround you could first check in files in folder src\ProjectA and then exclude others, after the gated check-in build completed, include other files again.
For more info of the TFVC gated check-in, you could take a look at James Reed's answer in this question Can we build multiple gated check-ins in parallel?
I'd like to run a build from an older changeset. When I go to the Builds (in VS2015 or in TFS in the browser) and then select "Queue New Build..." I can select a shelveset name in the dialog that pops up. However I see no option for selecting a a changeset. I thought this was possible in a previous version of VS.
You can achieve it by specify the changeset info in Source Version of queue build dialog such as C8 which will build changeset 8. More detail explanation please see below screeshot.
Note: This function is released with TFS2015 update2. To use it, you have to upgrade to Update2 or above.
If you're using the old XAML-based builds, not "Build vNext", then you should be able to specify a changeset in the "Get Version" property in the advanced section of the "Parameters" tab on the "Queue Build" dialog.
I maintain our build process on our TFS 2012 system.
Up till now I've been making changes locally to a solution that generates our custom activity DLLs. These DLLs are checked into TFS and are used by the build controllers and agents for the custom activities in our custom build template.
For all of my code and workflow activities I have a unit test library that I can locally run to put in some base test values. While this gives me a good idea at how my custom tasks will run it is not optimal.
What I would like to be able to do is run the entire build definition. Is there a way to test the whole build process locally so that I can be sure that my changes to the workflow are acceptable before checking in and kicking off a build? Right now my builds take between 30 and 40 minutes to complete and I would like to be able to start, monitor, debug, and stop the build locally without occupying one of our agents.
Edit
Another method for me to solve this problem is to come up with some manner to execute the workflow that is the build template locally. Has anyone been able to do this?
Take a look at the Ranger Build Customization Guidance. There is a HOL for doing a lot of this. It doesn't look like it is in v2 so take a look at v1.2.
http://vsarbuildguide.codeplex.com/releases/view/87995
If I am understanding the issue correctly, one way to do this may be:
Install a build agent locally and register it with the TFS Build Controller.
Give the new agent a custom tag so it doesn't get assigned other builds from the queue
Shelve your changeset
In VS, right click the build definition you want, and select queue new build. A "Queue Build" window will open
Under the general tab, "What do you want to build", select your shelveset.
Under Parameters tab ->Advanced -> agent settings, enter your agent's tag.
Click queue.
I accomplish this using a modified version of #malexander recommendation.
Create a code branch in TFS, commit your changes there, especially the changes to your custom activity DLL's (compiled binaries, not just source).
Install a TFS Build Controller and Build Agent locally, registering the controller with your TFS server.
Configure your new local controller to use your modified custom activity DLL's, stored in your new TFS code branch. Team Explorer > Builds > Actions > Manage Build Controllers >
(select your new local controller) > Properties > Version control
path to custom assemblies
4.
Queue a new build, from an existing TFS build definition: change its controller to use your new local controller.
The new build will execute on your local controller/agent, using your modified custom activity DLL's, without interfering/restarting your production agents.
Also: since you're in your own code branch, you can commit debug versions of your custom activity DLL's, without impacting your production agents.
Is there a way to create a build definition, in TFS 2010, that uses continuous integration trigger, and only builds the project who's code changed.
To clarify, what I'm searching for is the following scenario:
1 Solution
x Projects in Solution
1 Build Definition per Project
All Builds are CI triggered
When a check-in occours in a project only that project gets built and tested.
Place in your build definition's "Items to build" section of the "Process" tab any *.*proj instead of a *.sln.
In the "Workspace" section, select only the source control paths that relate with this project.
In the process tab, set "Clean Workspace" to "None", use "/t:Build" on the "MSBuild Arguments" and properly configure your projects and their dependencies in the solution. This way on each build, you will be getting the latest code, and then building whatever was modified, and anything that depends on it. This is much more dynamic and requires only one build definition. Let the build system operate as it was designed and leverage the optimized build process.
Currently we have a team project setup like below (in regards to branches)
Team Project
|__Developement
|__Development - Isolated Feature Dev
|__Main
|__Production
The issue that i have, is that when we want to do a team build on the production branch solution, it copies the entire team project down to the build server (so 4x copies, 1 for each branch) As the project is rather large, and the other branches are not required to be built, i'm wondering if there is any way to only build the single branch required?
When you configure the build, on the workspace tab, choose the correct branch in source control.
If you only want to check out the Development branch, configure the build to check out
$/Team Project/Development
If you want to check out a particular folder, but not sub-folders, you can 'Cloak' the sub-folders. Right click on the build from Team Explorer, chose "Edit Build Definition", and click the 'Workspace' tab.
From there you can cloak/add as many folders (branches are just folders) from as many places as you like