Grouping configurations to enable sequential running.
Hi,
Is there anyway to group configs to stop them runningconcurrently?
Without having to put all into one great build config.
A basic example:
Version control check-in causes Config A to trigger and App A be built.
Config Atriggers Config B to deploy App A
Config Btriggers Config C to run tests against App A
Version control check-in causes Config 1 to trigger and App 1 be built.
Config 1triggers Config 2 to deploy App 2
Config 2triggers Config C to run tests against App 1
WhenConfig C is running we don’t want Config B or 2 to run as it will disrupt thesystem testing.
This is just one example…
So we just need a way to group the configs together so theyare always run sequentially even if agents are free.
I believe this issomething done in other build software; just not sure how to do it in TeamCity. I think that the equivalent in CruiseControl is build queues, they have multiples of these which means only one thing in each build queue gets built at a a time.
Cheers,
Andrew
Please sign in to leave a comment.
Hi Andrew
Snapshot dependencies between build configurations do exactly that. Moreover, they allow to synchronize source revisions used in whole build chain, so tests are always correspond to production code.
H Michael,
Unfortunately snap shot dependencies do not prevent runs from occurring concurrently. To show you what I mean I have constructed a test setup:
Our requirement is that the SystemTest, DeployA and DeployB should never run concurrently as running a deployment while testing will kill the test. As can be seen below they are running concurrently.
Is there a way around this?
Cheers,
Andrew
Hi
In such configuration DeployA and DeployB configurations can be running in parallel.
But if SystemTest has snapshot dependencies on two configurations, it must trigger both of them, and wait until both of them have been finished.
How long SystemTest builds are? Maybe you have very fast compile/deploy builds and slow testing build. In such case new set of commits is begins to deploy before testing of previous deployment has been finished.
Groovy plugin may help to setup resource locks.
Hi Michael,
The system test is long, you are correct the new commits cause a deploy before the system test finishes, or somebody can start a manual run of a deploy while the system test is still running. Bear in mind that this is a simplified example as we have many test configs, builds and deployments. How can the Groovy plugin help? We currently have to keep a list of configs in a db and add a build step to make sure only one can run at a time. Is there any future development for adding this type of functionality to TeamCity. CruiseControl achieves this using seperate build queues (as far as I am aware).
Best Regards,
Andrew Fraser
The plugin allows to add system.locks.readLock.<lockName> property to deployment and test build configurations, so only one of such build can be running at a time, and all othe builds are kept in a queue.
Fantastic, I will try the plugin and let you know how I get on.
Best Regards,
Andrew Fraser
Hi Michael,
The build configs are now behaving as we require. Thank you for the assistance, it is much appreciated.
Best Regards,
Andrew Fraser
Hi Michael,
The plugin does the trick. Thank you very much for you assistance.
Best Regards,
Andrew Fraser
Hi Michael,
The plugin does the trick. Thank you very much for you assistance.
Best Regards,
Andrew Fraser
Just for reference: a feature request for the dedicated feature in TeamCity.
Hi Yegor,
Thank you for the reference, I have voting for the feature.
Best Regards,
Andrew Fraser
PS Apologies for the double post...