Is using TeamCity snapshot dependencies sufficient and appropriate to prevent breaking changes being available to the next QA build?

Question

I am attempting to configure a TeamCity project to be built. We have a CI build and a QA build.

We would like changes not to appear in the pending list of the QA build until the CI build has been successfully completed.

We would like the QA build to be triggered manually, as currently happens.

I have looked at creating a Build Dependency and Build Chain. The documentation for snapshot dependencies says:

a queued build does not start until all its snapshot dependency builds are finished. Depending on the snapshot dependencies options and status of the dependency builds, build can start or just marked as failed to start without running;

This doesn't say whether the changes that triggered the build will appear in the pending changes for the QA build before the dependent (CI) build is complete.

I considered using a gated checkin so that any breaking changes are not even committed but this seems to depend on an IDE. We currently use git so I don't think we can do this.

My question is twofold: 1. Is using snapshot dependencies sufficient and appropriate to prevent breaking changes being available to the next QA build? 2. If not what is a better way of achieving this.

Thanks in advance for any help.

hey, check this blog post about dependencies http://log.ld.si/post/teamcity-dependencies-101 if you still need help contact me — Dejan Dakić, Nov 07 '14 at 12:12
Thanks. Both your's and Sam's responses helped resolve this, but I couldn't up-vote your comment. — Baydr Earles, Nov 10 '14 at 16:49

score 0 · Accepted Answer · edited May 23 '17 at 12:20

My understanding is this:

You changes will appear to be available to the next QA build, but if the dependencies are set such that the QA build must use sources from a previously successful CI build then the QA build will not be able to be completed successfully unless the CI build is also passing. when you manually trigger a QA build it will look to see if there is a valid and available CI build with the same sources and if there is will start the QA build. if there isn't then it will trigger one so it can get the sources it needs. If the CI build fails then the build chain will be failed and the QA build will be failed.

It is possible to use gated checkins for your git repositories, see my answer here, which will ensure that the QA build can be made at the current 'head' of the 'green' repository

Is using TeamCity snapshot dependencies sufficient and appropriate to prevent breaking changes being available to the next QA build?

1 Answers1