Snapshot dependencies

I would like to have only the projects that have changed code or changed dependencies to build... not all projects in the build chain.

I setup a few simple code and build projects to see if I could accomplish this.

GreetingsInterface - holds interface Greetings
GreeintsImpl -  class GreetingsImpl implements Greetings
Conversation - uses GreetingsImpl

If Greetings changes, then all 3 should build.
If GreetingsImpl changes, then only GreetingsImpl and Conversation should build.

But if in GreetingsImpl build configuration I say GreetingsInterface is a snapshot dependency, then if GreetingsImpl changes, Greetings will re-build.

So to only have changed projects build I need to say :

Greetings has snapshot dependency to GreetingsImpl
GreetingsImpl has snapshot dependency to Conversation
Conversation has no snapshot dependencies.

Is this correct?  It seems backward. It seems like the I should be able to say
Conversation has a snapshot dependency on GreetingsImpl
GreetingsImpl has a snapshot dependency on Greetings
Greetings has no snapshot dependency

Can someone give me some clarification on this?

Thanks,

Scott Knowles

11 comments
Comment actions Permalink

TeamCity does not know anything about classes. TeamCity operates with VCS roots and build configurations. If Greetings and GreetingsImpl are in the same VCS root and at least one of these files is modified then all builds will always be triggered because these builds contain changes. If these classes are in different VCS roots and corresponding configurations have different VCS roots then TeamCity can reuse builds (take already finished builds) if this option is enabled for snapshot dependency.

0
Comment actions Permalink

I understand TeamCity does not know anything about classes.

I just want to configure my build projects so only projects with changed code or changed dependencies build when a developer checks into the VCS.

Should I use snapshot dependencies or just use build triggers?

If I use snapshot dependencies how do I prevent all the projects in the build chain from being built?

C -> B -> A
C has a snapshot depedency on  B
B has a snapshot dependency on  A
If B changes, then only B and C should build... not A.

What I see is if B changes then B, A and C get built.

Hopefully that clears it up?

Thanks,

Scott Knowles

0
Comment actions Permalink

Also realize that each Project has Build Trigger Rules setup so changes have to happen in their project directories, not just in the same VCS root.

Thanks,

Scott Knowles

0
Comment actions Permalink

Build trigger rules are about build triggering not about changes detection. Most likely this is the cause of your problem. If you want to exclude some changes from the build configuration you need to use exclude rule in checkout (not VCS trigger) rules. Checkout rules can be specified for each VCS root in build configuration at the "Version control settings" page. Something like this:
-:path/to/dir/to/exclude

In this case not only the changes in this directory will be ignored, but the whole directory "path/to/dir/to/exclude" will not be created on the agent.

In general snapshot dependencies are useful if your project consists of several layers which are developed by different teams in parallel. For example, these can be Presentation, Application and Storage layers. When new method or class appears in Application layer you may want to use it at the Presentation layer. In this case it is important to tell TeamCity that Presentation depends on Application so that TeamCity always started builds in correct order and with sources taken on the same moment of time. Results of the Application build can be represented as artifacts and reused in Presentation build.

If TeamCity does not know about dependency between Presentation and Application then if you make a change which uses new API your Presentation build may take artifacts of an older build of Application where such changes are not yet exist.

Another example is multipart build. I.e. a build which is built from different parts, with distribution packages for several different platforms or with parts written on different languages. Artifacts of such multipart builds must be consistent, they should not contain parts built from different changes. For example, TeamCity itself contains plugins, .NET part of an agent, Java part of agent, server module, notifiers, IDE plugins. These parts are often built by different build configurations. We have one master build configuration which depends on these configurations by snapshot dependency. This master build only accumulates artifacts. But with snapshot dependency we can be sure that all parts were built from the same sources. I.e. there were no changes in IDE plugin which use new remote API of the server side.

0
Comment actions Permalink

So if I have project called X and I only want X built when *.cs files under the X folder are checked in where do I tell TeamCity?

Thanks for all your help,

Scott Knowles

0
Comment actions Permalink

There are two cases:
- if you need these files in the checkout directory to create a build but do not want to trigger a build if these files are modified you should use VCS trigger rules. Note that changes will still be detected in these files and shown in the web UI.
- if you do not need these files in this build you should use exclude them with help of checkout rules. However checkout rules are not supporting wildcards at the moment.

0
Comment actions Permalink

VSC trigger rules are for firing off a build when files are checked in.
So I can say when files "*.cs" are checked in to the VCS, buld my project.

Checkout rules are for excluding files from checkout from source control, but not for build triggering.

Correct?

Thanks,

Scott Knowles

0
Comment actions Permalink

Yes, this is correct.

0
Comment actions Permalink

How is this master project configured?  All snapshot dependencies and artifact dependencies?  No build dependency triggers.

I have a master project and a series of interdependent projects and I'm having trouble getting the projects configured correctly.

Why do I need to set snapshot dependencies, artifact dependencies and build dependency triggers on each project?
Can I just set artifact dependencies on each project and only set the snapshot dependency on the master project?

Also if I have multiple build dependency triggers, so A has build dependency triggers on B and C.
If B runs and C fails, will A run?

Thanks,

Scott Knowles

0
Comment actions Permalink

I can't suggest you which dependency to use because I do not know details. Could you please describe your projects and how these projects builds should work?

0
Comment actions Permalink

I got the configuration figured out.

I needed a master project that only build if all of the projects built sucessfully.

So I have a master project that has all the other projects as snapshot depedencies, artifact dependencies and VCS build triggering on any check-in to the VCS.

All the other projects just define their snapshot and artifact depedencies.

When a check-in happens the master project builds and adds all of it's snapshot dependencies to the build queue.
TeamCity then figures out which projects need to build and which don't.

If everything builds without failure... then the master runs.

Thanks for all your help.

Scott Knowles

0

Please sign in to leave a comment.