4

I have a TeamCity project with a few types of build configurations:

  • Application packages, containing various application components and built from various subtrees in version control
  • Role packages, combining the application packages together in different configurations (app server role has common code + front end, web services role has common code + back end, etc.)
  • Regression test, a series of build steps that deploy the role packages on corresponding test servers and run a lengthy Selenium test suite

The goal is for the application packages to be built frequently so we know immediately when a unit test has broken, the role packages to be built as needed, and the regression test to run as often as possible when there are new role packages to test. But since the regression test takes a long time and only one regression can run at a time (it monopolizes the set of test servers), we always want it to pick up the newest available packages at the time it starts running. For example:

3:00 code checked in
3:01 build app package (A1)
3:02 app package A1 finishes
3:02 build role package (R1)
3:03 role package R1 finishes

3:04 regression starts for R1

3:10 code checked in
3:11 build app package (A2)
3:12 app package A2 finishes
3:12 build role package (R2)
3:13 role package R2 finishes

3:20 code checked in
3:21 build app package (A3)
3:22 app package A3 finishes
3:22 build role package (R3)
3:23 role package R3 finishes

3:30 regression finishes for R1
** regression never runs for R2 **
3:30 regression starts for R3

So far, I've implemented this using artifact dependencies and build triggers:

  • Application packages are triggered by a Schedule Trigger, restricted to the relevant source code with VCS trigger rules. They have no TeamCity dependencies.
  • Role packages are triggered by Finish Build Triggers pointing to all the relevant application packages. Each one has artifact dependencies on the relevant application packages (last successful build).
  • Regression test is triggered by Finish Build Triggers pointing to all the role packages, and restricted to run on a single agent. It has artifact dependencies on all the role packages.

This works well enough when only a single role is rebuilt. But when more than one role changes at the same time, the regression test starts running as soon as the first role is rebuilt, and then the rest of the roles don't get picked up until that test finishes. I want the regression to start running when the last changed role is rebuilt. (Note: there are more roles than agents, and the regression runs on a different agent from the package builds.)

Snapshot dependencies sound like the tool I need... but my understanding is they force all dependent configurations to run from the same VCS revision, and I want to avoid forcing a package to be rebuilt if its code hasn't changed. If the only change today is in a package that only affects role R, then roles S/T/U shouldn't be rebuilt and neither should their dependencies. Is this possible?

Edit: I'm running TeamCity 7.1.1.

infojolt
  • 4,786
  • 2
  • 28
  • 72
Jesse McGrew
  • 1,819
  • 17
  • 28
  • Did you get this working in the end? We have a similar situation and it currently looks like my only option would be to write some code that has this logic built into it (e.g. a custom trigger or a PowerShell script that makes use of the REST API) – Stephen Edmonds Jan 27 '15 at 12:02

1 Answers1

1

I think that a snapshot dependency with Do not run new build if there is a suitable one and Only use successful builds from suitable ones alongside an artifact dependency with build from the same chain set will do what you want. This configuration should mean that it sees there is no need to rebuild because nothing has changed, note that it still triggers the build but all it does is evaluate that there is nothing to do so continues on with the build chain.

NB: You don't mention which version you're running but I believe this did not work properly in 6.5 but does work (more optimally) in 7.1.

Matt
  • 7,811
  • 3
  • 26
  • 56
  • It sounds like I'll also need to set up checkout rules for each project (instead of only using trigger rules), otherwise TeamCity won't be able to detect that nothing has changed. – Jesse McGrew Dec 11 '12 at 23:02