Do dependencies by sources have a heirarchy ?

No same sources dependency works one way only. You probably have dependency trigger configured in A build configuration.

--
Pavel Sher

I've done more testing and seen unexpected behaviour. Let me explain in detail.

This is our configuration:

• We have two build configurations: core and extension.

• Both configurations have a VCS trigger.

• They don't have any other trigger (No dependency trigger).

• extension has a dependency by sources on core. It also has an artifact dependency.

The unexpected behaviour I'm finding is this: After a regular VCS changes check takes place, if there are no changes in core but there is a change in extension, then core still gets rebuilt with extension following it in the build queue.

When I looked in the overview tab at what triggered the rebuild of core I saw "Triggered: by CVS; Project::extension on 04 Nov 08 10:34"
(extension says it was "Triggered: by CVS on 04 Nov 08 10:34")

Why does TeamCity 4.0 rebuild core even though there aren't any changes to it ? Is there a way around this ?

Thanks
Hussain

What options do you use for your dependency? Have you turned on the "Take already started build with same revisions" option?

--
Pavel Sher

Yes. The options turned on are "Take already started build with same revisions" and "Take successful builds only".

Do you use the latest EAP build (#7888)? If so could you please submit a bug in out tracker and attach there screenshot of "extensiotn" dependencies configuration page. Also please attach a history (screenshot is ok) of the core and extension builds.

--
Pavel Sher

Yes I'm using the latest EAP (#7888) and have submitted a bug report: http://jetbrains.net/tracker/issue/TW-6085

Hussain

There may be another problem in the opposite direction: If a change is found in core then only core gets rebuilt. extension doesn't get rebuilt which is wrong because core could be a library and a change in its interfaces could break extension. So obviously we want extension to be rebuilt as soon as possible.

Right now you can use dependency trigger. You can add dependency trigger in extension to depend on core. In this case new successful finished build will trigger extension build. The only limitation is that extension build will be triggered only if core build is successful, this behavior is not configurable. We will see what we can do with it in 4.0.

--
Pavel Sher

If I add a dependency trigger then I run into another problem: If both core and extension have changes then extension gets rebuilt twice. ie there is an extra, unnecessary build just because of the dependency trigger. Obviously this will multiply many times if we have a deep dependency hierarchy.

Can you improve the dependency trigger so that before triggering extension it checks if extension is already on the build queue ? If so then it shouldn't trigger it.

Another possible workarounds:
- modify checkout rules of the extension configuration to include changes from the core build configuration
- create another build configuration which will include sources of core and extension and will depend on extension by sources, and enable VCS trigger in this configuration


--
Pavel Sher

Modifying the checkout rules to include parent builds has the downside of causing unnecessary files to be checked out and placing additional load on the cvs servers. Creating another build configuration is a bit of a kludge.

My suggestion about changing the dependency trigger to skip triggering a build if the build is already on the queue is actually a fix rather than a workaround. I think this is an important issue to address, whichever way you fix it. Otherwise the dependency enhancements, which are the most important changes in 4.0, will be incomplete.

Hussain

Since the triggering of build and queue flushing are made independently in separate threads it can be too late to check the queue in the dependency trigger (build can be already started). Anyway thank you for your suggestions, we will see what we can do.

--
Pavel Sher

Just to enrich the discussion, one possibly neat way to do this is to allow extension to specify the trigger patterns for core without modifying the checkout rules. So core still has checkout rule +:core and extension still has checkout rule +:extension.

But now extension is allowed to have two trigger patterns: both +:core/** and +:extension/**. I've checked that this is not possible in the current build - apparently trigger patterns cannot go outside the scope of checkout rules. Obviously I have no idea if it's an easy change to make or how well it will fit in with the dependency by sources mechanism. Sorry for going on about this, just a thought.

I've submitted an issue: http://jetbrains.net/tracker/issue/TW-6128

Let's discuss possible solutions there.

--
Pavel Sher