How to prevent specific jobs from running simultaneously?
I'd like to configure TeamCity so that some specific jobs (say Job A and Job B) should not run at the same time.
This is because Job A and Job B run tests against a database that is a shared resource and both jobs need exclusive control of the database. The database is expensive, otherwise Job A and Job B would have their own ones. Job A builds a different executable and runs on a different server to Job B - they're unrelated apart from the fact that they contend a critical resource.
Could someone please tell me how to configure this in TeamCity 5?
I know that a specific job can be made to run only once and I suppose that this is to protect a non-shareable resource that the job uses. I need something that goes further and says 'don't run this job while this other job (or jobs) are running'.
Please sign in to leave a comment.
Hi Tim
Take a look at this recent thread, it looks similar.
http://devnet.jetbrains.net/message/5283327
Also you can vote for TW-3798.
Michael
So for anyone reading this post in isolation... am I right in saying that what we need to do is:
1) Install the Groovy Plugin. Although the solution does not need Groovy directly, it will provide the required functionality in TeamCity 5: http://confluence.jetbrains.net/display/TW/Groovy+plug
2) On each build job that requires exclusive access to a shared resource eg a database, set the system property: system.locks.writeLock.sharedDatabase=true
where the value 'sharedDatabase' is just the arbitrary name of the lock.
I'll report back on how this works once our CM has installed the Groovy Plugin - have people found this to be a straightforward process?
The instructions for the plugin
http://confluence.jetbrains.net/display/TW/Groovy+plug
refer to a standalone installation of TeamCity. How do you add this plugin to TeamCity deployed as a war file? Are the follow steps right?
Download all files to the same directory and place in it a copy of the teamcity.war file.
mkdir -p WEB-INF/plugins
mkdir -p WEB-INF/lib
mv groovyPlug.zip WEB-INF/plugins/
mv antlr-2.7.7.jar WEB-INF/lib/
mv asm-2.2.3.jar WEB-INF/lib/
mv groovy-1.6.4.jar WEB-INF/lib/
jar uf teamcity.war WEB-INF
Redeploy the teamcity.war file
Is this right? I'm concerned about mixing versions of ASM here and making TeamCity unstable - there is an asm-3.1.jar for the REST API and version 3.0 for the coverage plugin.
Sorry for being so pedantic but I it's unfair on our developers to mess around with our TeamCity install too much. I'll not be popular if I break it.
Tim,
You should rather follow the installation procedure specified on the plugin's page.
That would be something like:
mkdir -p path_to/.BuildServer/plugins
mv groovyPlug.zip path_to/.BuildServer/plugins/
mv antlr-2.7.7.jar WEB-INF/lib/
mv asm-2.2.3.jar WEB-INF/lib/
mv groovy-1.6.4.jar WEB-INF/lib/
Different versions of asm in REST API and here should not be a problem (since REST API uses separate classloader).
I'd recommend trying the plugin out at a test installation of TeamCity first - just to be sure before affecting the production server.
Tim,
Yes, this is right.
> have people found this to be a straightforward process?
No big complains so far, but of course, this is a workaround for the feature. That is why the feature request still has Open state in the tracker.
I actually found that it worked by updaing the Team City war file so that it included WEB-INF/plugins/groovyPlug.zip worked for me (and including the other dependencies in WEB-INF/lib).