Coorelation between check-ins and number of triggered builds?

Oct 16, 2007 at 9:28 PM
Edited Oct 16, 2007 at 9:32 PM
Before I get too far in generating sequences of check-ins to test this out on my own, I'm wondering if one of the TFSBuildLab authors or users could confirm TFSBuildLab's expected behaviour when CI triggers have been configured for multiple build types, a build is queued and begins executing, and then a variety of further check-ins take place, each matching the requirements of the same and/or other build types, where multiple triggering check-ins take place for each build type. My expected/desired behaviour would be for TFSBuildLab to only queue one outstanding build per build type, rather than one per check-in. Is this a correct assumption?

By way of example if that helps:

Imagine for a moment that branch A is building and the following check-ins take place before the branch A build completes:
  • trunk
  • branch A
  • branch B
  • branch B
  • branch A

I would expect to see the following in the queue and nothing else:
  • trunk
  • branch A
  • branch B

If the branch A build completes, trunk then starts building, and the following check-ins then take place before the trunk build completes:
  • branch B
  • branch B
  • branch A
  • trunk
  • branch A

I would expect to see the following in the queue and nothing else:
  • branch A
  • branch B
  • trunk

Make sense?
Coordinator
Oct 16, 2007 at 10:01 PM
You are correct in your assumptions this is exactly the way the service behave. If a build with multiple checkin on it breaks it will send out an email to each of the contributors that checkin from the point when we queued the build and when we actually started it.

/Peter
Oct 16, 2007 at 11:02 PM
Perfect. Thanks for the quick confirmation.
Oct 24, 2007 at 2:19 AM
Edited Oct 24, 2007 at 2:20 AM
FYI, I can confirm from staring at my TFSBuildLab admin GUI right now that this feature is not behaving as specified. I am currently showing the following:

Branch A is building.

Trunk, Branch A, and Trunk are queued.

There should only be one entry of Trunk in the queue, based on your description of TFSBuildLab's intended behaviour.

If it makes a difference, the first entry of Trunk in the queue is not showing anything in the TriggeringChangeset column, whereas the other two entries are.
Coordinator
Oct 25, 2007 at 1:27 PM
Sorry Jeremy,

I might have misslead you, currently it works this way:

1, Branch A receives checkin 1
2, We post a build request for checkin 1
3, Build of checkin 1 starts (altough it will use the latest available source unless you do some fancy stuff, which is possible through the parameter override feature)
4, Branch A receives checkin 2
5, We post a build request for checkin 2
6, Branch A receives checkin 3
7, We see that a build request for the build type of branch A is already queued and skip this request.
8, Repeat step 6-7 until the queued build starts.

This means that there will only exist one queue item for a build type at any given type. But as soon as it starts the queue is free to recieve another queue request.

Is there any particular pattern you wish to use? I'll help you implement this, I can imagine that you wish to restrict the queue to not add a build request when another is in progress? Remember though that once the build starts and you perform an additional checkin you will have a new version of the code that might break the build, thus it is a legit pattern i regards to continous integration.

Let me know what you needs are for this and I'll fix this issue.

/Peter
Oct 25, 2007 at 10:34 PM
I can confirm for you that a redundant build is most definitely queued. I'd have to monitor things and watch the build logs to see if the redundant build actually gets run.

By "skip the request" in step 7 in your email, do you mean skip as in you won't run the queued build? Or skip as in no build will be queued?
Coordinator
Oct 26, 2007 at 7:26 AM
Skip as in skip queueing the build, there should only exsist one queue request for a given build type at any given time in the build queue that is the way we have intended it and as far as I have tested on our site it works I'll look into it.

It would be greatly appreciated if you could give me a scenario description in step form so I can reproduce the behaviour myself.

/Peter
Oct 26, 2007 at 11:27 PM
I don't monitor the queue super often, but I'll try to keep a bit more of an eye on it for you and let you know if it happens again.