Multiple Build Agents - question

Hey guys,

We have two build agents set up now.

Just noticed that when DeveloperA checked into ProjectX and 5 mins later, DeveloperB also checks into ProjectX that his check-in kicked off a second build even though DeveloperA's first build has not even completed.

Somehow this seems strange to me. I would like to see the first checkin complete (and either pass or fail) before a second build on the same project is kicked off.

Is there a way to configure TC so that our second agent is never "used up" to start running a build on a project that is already building??

This seems like a waste of processing, I mean, why would you want to be running two separate builds simultaneously (just staggered) on the same project?


Thoughts?


Thanks!

6 comments

You can limit number of simultaneously running builds in a build configuration on the General serttings page.
BTW it is useful to have several builds running simultaneously because it simplifies investigation of possible test failures - the lesser number changes in each build - the faster you can find the cause of the failure.

0

You can limit number of simultaneously running builds in a build configuration on the General serttings page.

>> Thanks !!!  This should address my issue.


BTW it is useful to have several builds running simultaneously because it simplifies investigation of possible test failures - the lesser number changes in each build - the faster you can find the cause of the failure.

TC2.JPG


>>  I actually don't understand why you would want several builds simultaneously running (see pic above)...like "B" starting to run without "A" having finished. If "A" fails, 99.9% of the time "B" will in turn fail. So would you not agree that it was a waste of processing power (and the waste of an Agent) to be running "B" in the first place without waiting for "A" to finish? In particular when you have long running builds...this is not an issue really if builds are 5 mins long, but in this case they are 45 mins long.

Seems to me that the TC default is 0 for "Limit the number of simultaneously running builds (0 - unlimited)" is that correct. If so why is it this (why not 1)

Am I missing a key concept here?

Thanks for your feedback.


CK

0

Let's look at this from the developer point of view. He checked in a fix and once TeamCity detected a change a build was started. Isn't it good for developer to see status of his changes immediately?

In your screenshot it seems build A did not have changes, while build B had. I do not know while build A was started (maybe it was triggered manually), but I definitely would not say that build B is a waste of processing time - it runs build with changes, and this build can behave differently. Note that usually TeamCity starts builds when changes are detected (if VCS trigger is enabled), moreover some of our users asked to implement feature to start builds so that each build run with one change only, becuase it greatly simplifies search for changes that lead to test failures.

Note that with help of trigger rules on VCS trigger page, you can disable triggering for some files. For example, if you have *.html files in your project and changes in them may not affect build status, you can disable triggering for changes with such files.

0

>> Sorry my screen-shot did not reflect the exact scenario, but my description was correct. A and B were building simultareously.



"Isn't it good for developer to see status of his changes immediately?"


>> Yes. So this is my point. Why would I ever want a long running build to be building simultaneously (A and B) when it would be more useful to someone to see the status of their changes on another configuration more immediately by using the second agent to actually kick off their build...not have a double agent running under a single configuration.

Anyways, I see your point for some cases, but I see my point for my particular case which is, very few build agents (but more than 1) and some very long running builds. I see it as more beneficial to provide quick feedback across the entire application (multiple projects in TC).


"moreover some of our users asked to implement feature to start builds so that each build run with one change only"

>> What does this mean with "one change" only? Do you mean a set of changes? Can you explain this more plz/

"Note that with help of trigger rules on VCS trigger page, you can disable triggering for some files"

>> That is a great idea, we have not done this yet but obv is a fantastic addition to be added in (carefully of course) esp on long running builds.

0

If you do not have enough agents and builds are slow, then indeed you may want to include as much changes in the build as possible.

By "change" I mean a single changelist detected by TeamCity (containing comment and a number of changed files). Some users want their builds to run with single change only. In this case it is obvious whom to blame if build fails.

In your case you can limit the number of simultaneously running builds. You can also specify quiet period for VCS trigger (http://confluence.jetbrains.net/display/TCD5/VCS+Triggers). In either way the effect should be similar - builds will run more rarely and will include more changes.

0

Yes you are right, we are considering the quiet period settings for some of our configurations.

Pavel, thanks for your insight and quick feedback.

Much appreciated.

CK

0

Please sign in to leave a comment.