This project is read-only.

General

May 1, 2007 at 7:47 PM
Edited May 1, 2007 at 7:48 PM
This discussion group is for general discussions about features in TFSBuildLab.
Sep 13, 2007 at 3:34 PM
I'm wondering if this project will address continuous integration for branched projects? In other words, if I have several branches, when a change is made to one, I don't need the mainline build to kick off - just a build for the modified branch. The current mechanism I am using for CI simply starts a pre-defined build anytime ANYTHING in the team project changes. I'm really hoping this is something being addressed here.

Can anyone on the team comment on this?
Sep 13, 2007 at 8:10 PM
Is the CI build able to get the source up to the changeset that triggered it, or does it always just get latest?
Sep 13, 2007 at 8:45 PM
Yes, TFSBuildLab supports CI for any path in your repository using what we call Build Events. See http://www.codeplex.com/tfsbuildlab/Wiki/View.aspx?title=Adding%20a%20continous%20integration%20build&referringTitle=Quickstart for details on how to define build events. Also see the more detailed documentation about the build event feature here: http://www.codeplex.com/tfsbuildlab/Wiki/View.aspx?title=Build%20Events&referringTitle=User%27s%20Guide.


tdallmann wrote:
I'm wondering if this project will address continuous integration for branched projects? In other words, if I have several branches, when a change is made to one, I don't need the mainline build to kick off - just a build for the modified branch. The current mechanism I am using for CI simply starts a pre-defined build anytime ANYTHING in the team project changes. I'm really hoping this is something being addressed here.

Can anyone on the team comment on this?

Sep 13, 2007 at 8:56 PM
Currently we just kick off the build connected to the build event. Unfortunatly there is no easy way to pass parameters to TFS/Team Build so we cannot pass the CS number. Peter is working on a solution to solve this and hopefully that will work (and will be included in the v1 release). So if you find it valuable to build from a specific changeset we can have a look at how we can bring that into TFSBuildLab.


DavidSutherland wrote:
Is the CI build able to get the source up to the changeset that triggered it, or does it always just get latest?

Sep 13, 2007 at 9:10 PM
Edited Sep 13, 2007 at 9:11 PM
Thanks for your reply. Yes, I would find that extremely valuable. I don't currently use TFSBuildLab (we wrote our own solution for CI builds), but may be willing to switch if it had this capability.

Our current system kicks off a CI build when someone checks in, and that build is updated to be "Requested By" the checkin committer. If another checkin occurs and triggers a CI build while one is in progress, it queues up another CI build by that committer.

The problem is that each CI build can only pull the latest source, so if one CI build in the current queue breaks, it's difficult to tell accurately who may have actually broken it. Being able to build by the changeset triggering the build would be a huge advantage here for accountability and for ensuring the right person is notified when their checkin causes a problem.


MOlausson wrote:
Currently we just kick off the build connected to the build event. Unfortunatly there is no easy way to pass parameters to TFS/Team Build so we cannot pass the CS number. Peter is working on a solution to solve this and hopefully that will work (and will be included in the v1 release). So if you find it valuable to build from a specific changeset we can have a look at how we can bring that into TFSBuildLab.

Sep 14, 2007 at 3:02 PM
You would be able to do this once our solution is finnished, altough it won't be a simple solution since you would need to override the CoreGet target in Microsoft.TeamFoundation.Build.targets since the implementation always defaults to getting the latest version. Fortunately the custom build task Get which does the actual retrival of the files to compile supports the property Version which allows you to specify this.

I'll be sure to test this and if it works we can include this functionality in v1 of TfsBuildLab.


DavidSutherland wrote:
Thanks for your reply. Yes, I would find that extremely valuable. I don't currently use TFSBuildLab (we wrote our own solution for CI builds), but may be willing to switch if it had this capability.

Our current system kicks off a CI build when someone checks in, and that build is updated to be "Requested By" the checkin committer. If another checkin occurs and triggers a CI build while one is in progress, it queues up another CI build by that committer.

The problem is that each CI build can only pull the latest source, so if one CI build in the current queue breaks, it's difficult to tell accurately who may have actually broken it. Being able to build by the changeset triggering the build would be a huge advantage here for accountability and for ensuring the right person is notified when their checkin causes a problem.