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'.

6 comments
Comment actions Permalink

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

0
Comment actions Permalink

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?

0
Comment actions Permalink

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.

0
Comment actions Permalink

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.

0
Comment actions Permalink

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.

0
Comment actions Permalink

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).

0

Please sign in to leave a comment.