Build priorities, snapshot + artifact dependencies - possible without making clean checkout happen?

I have several build configurations, all of which share the same VCS root and checkout directory:

  • Quick compile
  • Build for platform A
  • Build for platform B
  • Deploy for platform A and B

The VCS is SVN, and is done as a checkout on server rather than on agent. The repository is large and our connection is slow, so I want to avoid clean checkouts as much as possible - they take ~12 hours and dwarf actual build times.

The quick compile runs quickly to give an early pass/fail. The builds are much slower.

The quick compile and build for platform A are run on an VCS trigger. Platform B isn't.

The deploy step has a snapshot and artifact dependency on the builds for A and B, and is run nightly.

Recently I changed the quick compile to have a higher priority than normal, to make sure it ran before the build for A when triggered by VCS, in order to get faster feedback on failures to the team.

This has had the unfortunate effect that if the VCS trigger triggers in-between the builds for platform A and B when being run due to the deploy step dependency, then a clean checkout is forced, since when going back to the build for A or B an older version is needed to be checked out.

What can I do to stop a clean checkout happening in this situation? I can see three options but I don't like any of them:

  • Reset the priority of the quick compile - bad because I do still want it to happen first
  • Give all build configurations separate checkout directories - bad because they all take a lot of disk space, and there are several more platforms than just A and B in this example!
  • Use 'checkout on agent' - annoying because I'll have to install SVN on all agents which is a pain on Windows, also I don't even know if this will fix the problem, also all agents will need to do a full sync again... but maybe this is the best option available to me anyway.

There are two improvements that could be made to Team City that would fix this for me - would it be possible to implement either of these?

  • Allow 'checkout on server' configurations to build patches that change from newer to older revisions to avoid clean checkout in this situation - I don't know why this isn't supported anyway
  • Allow builds triggered because of snapshot/artifact dependencies to have a custom priority - I think in general it would be useful to be able to override priority per build anyway, perhaps in the "Run..." dialogue

If I've missed something and there's a better way, please let me know!

Thanks,

Ben

2 comments

Hello Ben,

Instead of using priority you can configure snapshot dependency (you can also use option "Run build on the same agent") between A and Quick compile configurations; and configure one VCS trigger for A build configuration with option "trigger on changes in snapshot dependencies" enabled. In this case Quick compile will always run before A build configuration and the same sources will be used. Will it work for you?

Do I correctly understand that you use custom checkout directory to checkout files? The recommended approach is to use auto checkout directory. In this case checkout directory will be reused if it's possible. See this section for more details.

 

0

Hi Alina,

I don't think that will work. I don't want the quick compile to happen before A because there's a dependency, but because it's a shorter build that gives quicker feedback, which means that priority is the best feature to use. With snapshot dependencies (and leaving priority as default), if the quick compile (I'll call it QC now) and A are in the queue using sources at Version 1, then someone commits Version 2 whilst QC is in progress, A at V1 will be run next, but I would like QC at V2 to be run in preference. Using priorities gets me what I want. Am I explaining that at all well?

None of the checkout directories are custom - QC, A and B all use auto, which is the same directory since they all use the same VCS. If I gave them all separate directories that would solve this problem since none of them would have to update to an older revision of sources in this example. But as I say, that's a bit messy, it goes against your advice, and it requires more storage space, so you're right not to recommend it :)

0

Please sign in to leave a comment.