Snapshot dependencies being built unnecessarily

We are running TeamCity Professional 2025.07.3 Build 197398.

I have a composite build configured to run a build chain that should only ever run the final build in the chain.

The chain comprises of the following:
Back End Server Solution → Web Tier Solution → Demo Data Creation project → Packaging and Deployment project

The expectation is that when I trigger this composite build, given that all snapshot builds are built and no further changes have been committed I would simply get the final project in the chain built.

However, I'm seeing a full rebuild of the entire change when the composite build is triggered.

I also have a second composite build, that is exhibiting the same behaviour.

The last dependency in the chain is configured as follows:
 

New build will use the same revisions as in the dependency
Do not run new build if there is a suitable one
Only use successful builds from suitable ones
On failed dependency: mark build as failed to start
On failed to start/canceled dependency: mark build as failed to start

The other dependencies are configured in the same way, but they also specify:

Run build on the same agent

This setting is not required for the packaging/deployment build.

 

0
18 comments
Hi,

If the dependent builds are being re-run, that means there are no suitable builds for reuse. Please refer to the documentation for what builds are considered suitable: https://www.jetbrains.com/help/teamcity/snapshot-dependencies.html#Suitable+Builds
The most common cause for builds not getting reused is customized parameters: https://youtrack.jetbrains.com/issue/TW-23700

Best regards,
Anton
0

Hi Anton,

Thanks for the reply, it's appreciated.

As far as I know, the snapshot dependencies should be suitable for reuse. This configuration was working as expected, but I can't be definitive as to when the behaviour changed. The snapshot dependencies were triggered by committed code changes and completed successfully prior to the deployment being manually triggered.

I don't know if this will make a difference but the next deployment we do I'm going to run the deployment from the deployment project rather than from the composite build project. It's unlikely to make a difference given the current behaviour but I need to try something.

Thanks again.

Regards,
Lou

0
Hi Lou,

In a case you'll reproduce the issue:
1. Determine the build that you assume should've been reused.
2. On the dependent build configuration's page, select the build that was executed last (i.e., the one that you think should not have been started), click on the ..., and select "Select for comparison".
3. Click on "Add second build" and select the build that you assume should've been reused.
4. You can then compare the two builds, determine their differences, and identify possible causes of the build not deemed suitable.
More information on build comparison: https://www.jetbrains.com/help/teamcity/build-actions.html#Compare+Two+Builds
Let me know if this helps.

Best regards,
Anton
0

Hi Anton,

Thanks for the build comparison hint, very useful.

Looking at the comparison, I have no differences in the User-Defined Parameters, there are differences in the agent parameters but those are to be expected. Looking at the Dependencies tab, “No differences in dependencies were found”. The Revisions tab, “No differences between revisions were found”. 

Cheers,

Lou

0
Hi Lou,

Could you please share the comparison for two such builds, as well as the build logs for both of them? You can upload it to https://uploads.jetbrains.com/ and share the upload ID.

Best regards,
Anton
0
Hi Lou,

Could you please share the comparison for two such builds, as well as the build logs for both of them? You can upload it to https://uploads.jetbrains.com/ and share the upload ID.

Best regards,
Anton
0

Hi Anton,

Thanks again for the follow up. I've uploaded the build logs and a screen grab of the comparison. If there's a way to save this as a report please let me know. Upload id is: 2025_11_25_wYzP3opkpB3FVQHVvtV6nf

These build logs are from the main back end project that is the start of our build chain.

Cheers,

Lou

0

Hi Anton,

A quick update for you. With this sprint's deployment, instead of triggering the deployment from the composite build configuration I triggered it from the deployment build configuration (this being the last configuration in the build chain).

There was no rebuilding of any of the dependencies, the snapshot dependencies that were already in place from git triggered builds were deemed acceptable and the deployment was the only configuration that ran. This is the behaviour I expect.

It's now looking like something in the composite build configuration is not correctly seeing the snapshot dependencies and triggering the extra rebuilds.

Cheers,

Lou

0
Hi Lou,

Do you use any reverse.dep.* parameters in the composite build configuration?

Best regards,
Anton
0

Hi Anton,

I've reviewed the Parameters tab on the last composite build I ran and there are no reverse.dep.* parameters.

Is there anywhere else I should be looking?

Thanks,

Lou

0
Hi Lou,

Please also refer to the documentation to confirm whether the build meets the criteria of a suitable build:
https://www.jetbrains.com/help/teamcity/snapshot-dependencies.html#Suitable+Builds


0

Hi Tom,

If you look at Anton's comment from November 10 he already provided that link.

As far as I'm aware the dependencies are suitable, and this can be demonstrated by running the final configuration in the build chain which is the deployment. Doing this, no rebuilds occur.

However, running the composite build configuration does result in a rebuild of the entire chain.

Cheers

Lou

0
Hi Lou,

I am unable to reproduce this issue on my side. With all snapshot dependencies in the build chain set to reuse suitable builds, only the snapshot build directly triggered by the composite build should be built.

This behavior is expected in my environment, as composite build configurations are “step-less” configurations designed to trigger multiple regular build configurations rather than rebuild all dependencies.

0

Hi Tom,

When I first set up these composite build configurations, the behaviour was working as expected. It was the reason why I wanted to set these build configurations up and they worked, and I got that “overview” perspective.

Then they stopped working as expected, it may have happened after a TeamCity update, but I can't be 100% sure if it was. I made no other configuration changes to the composite builds, nor to the build configurations in the build chain.

I might try a delete and recreate of these composite builds, maybe that will reset things somehow. It's something to try.

cheers

Lou

0
Hi Lou,

You are right. Composite configurations aggregate all information from their dependencies and present them in a centralized manner.

Please let us know the outcome after you’ve tested this approach.

If the issue still persists after recreating the composite builds, the next step would be to collect the full build logs and exact reproduction steps, so we can investigate this further with our development team.

Thank you for your patience and for sharing your observations. We’ll be happy to continue assisting you.

0

Thanks Tom, I appreciate yours and Anton's help with all this.

Cheers

Lou

 

0

Hi Tom,

I recreated the composite build configuration and I've just run it this morning and once again it's triggered a full build of the build chain. At this point I don't see any benefit in continuing with these build configurations. I can simply run the deployment build configuration, the last in the chain, directly and it will correctly detect the previously built dependencies and immediately run the deployment.

Thanks again.

Cheers

Lou

0
HI Lou,

Thank you for the update and for taking the time to recreate and test the composite build configuration.

I understand your conclusion. If your requirements change in the future. Please feel free to reach out.

0

Please sign in to leave a comment.