Snapshot Dependency TeamCity 10 - Behavior Change

Answered

Hi,

I've been using TeamCity 9.1.4 to build project A, dependent on two other projects, B and C, snapshots.

Build trigger was pull requests changes (configured in VCS branch specification).

In case of a new a pull request, all three builds, A,B and C were triggered (regardless to changes on B and C)

In TeamCity 10.0.1 I experience the following change:

Instead of triggering B and C, TeamCity says that snapshot dependencies are satisfied, based on other branch's previous build on the same revision instead of same pull-request/branch.

Is this thing new? Can I force snapshots to be on the same branch/pull-request?

Thanks!

6 comments
Comment actions Permalink

Hello Sharon,

There were no related changes. If a build configuration with branches has snapshot dependencies on other build configurations with branches, then when a build in a branch is triggered, the other builds in the chain will also get the branch associated, if the branches in the VCS roots of the builds have the same logical name and this branch is not excluded by the branch specification. Otherwise the default branch is used. Could you please attach screenshot of B or C branch specification?

0
Comment actions Permalink

Hi Alina,

All projects use the same VCS root, but have different checkout rules, and build different parts of the project. Each project-build matches only projects built from the same pull request (version enforcement - there is a step that inject pull-request id into version).

Therefore, snapshots must be used from same branch/pull-request, preferably re-used if possible. 

 

the VCS:

 

0
Comment actions Permalink

Could you please check that changes are not excluded by checkout rules in B and C build configurations? Also please attach teamcity-server.log and teamcity-vcs.log files. Thank you!

0
Comment actions Permalink

I'm seeing the same behavior with TeamCity 10, it looks like the "suitable build" heuristic for figuring out if dependencies can be reused is satisfied if it can find a build with the same revision (git sha1) even when the branch name differs.

In our use, we continuously build our whole chain for commits in the "master" branch (which is the default branch). Occasionally we push from master to a named release branch (release_xxx) and we use the release branch name in the build process along the chain, so we can't reuse the build artifacts from the default branch even though they are built from the same revision.

I'm pretty sure that the branch configuration is correct, since if I delete the "master" branch builds for a given revision and re-run the build chain the dependencies pick up the correct branch name (release_xxx).

I suppose the fact that our builds depend on the branch name is somewhat exotic and in many cases a matching build from the same revision should be suitable even if it was built with a different branch name, I'm looking for a way of communicating to TeamCity that the build actually depends on the logical branch name. Setting configuration params on the builds that resolve to the branch name doesn't seem to be sufficient.

 

 

0
Comment actions Permalink

If you experience problems with this behavior, please submit a bug report in our tracker. We'll think what we can do here.

0
Comment actions Permalink

We already have similar request: https://youtrack.jetbrains.com/issue/TW-47052
Please express your concerns there.

0

Please sign in to leave a comment.