Build delay/prevention dependency

Hi there,

We're curious to know whether you plan to implement (or already have) something
that could help with the following scenario:

We have the following build setup:
- a build config that gets triggered by changes in the java source tree.
It compiles the code and runs the unit tests. Some of the tests involve DB
operations
- a build configuration that monitors the DB subtree of the source code and,
when finding changes there, it updates the DB scripts and runs a DB update
with the new DB scripts. After that, a dependency build for the java unit
tests is triggered.

The following "conflict" is encountered every now and then: while the java
unit tests build is running, somebody checks in some DB related stuff. The
DB build is triggered and the running java build is messed up by the db changes.

Can some sort of wait dependency be provided? Something that would prevent
a build config from running while another one is in progress?

Is it to late to request such a feature for the next release?

Thx,
Andrei


3 comments

A related issue posted by Andrei is TW-5705.

Alternative approach to alike problem is to introduce resource tracking: TW-3798.

I encourage all interested parties to vote for either of the issues.

I am afraid, however, that we will be able to address any of them only in post-4.0 releases.

What is worth noting, though, is that having builds that modify some external resource, thus affecting all further builds imposes certain limits on usage of personal builds and history builds in TeamCity.

0

Andrei,

Actually, you are describing read and write locks: testing builds need read locks and db-updating build needs write lock. Write lock cannot be obtained while there are read or write locks. Read lock cannot be obtained while there is a write lock.

For the time being you can try to emulate the locking with file system lock files by modifying your build scripts to acquire a lock before actually starting the build procedure.

0

Hello Yegor,

YY> Andrei,
YY>
YY> Actually, you are describing read and write locks: testing builds
YY> need read locks and db-updating build needs write lock. Write lock
YY> cannot be obtained while there are read or write locks. Read lock
YY> cannot be obtained while there is a write lock.

Yes, you're right.

YY>
YY> For the time being you can try to emulate the locking with file
YY> system lock files by modifying your build scripts to acquire a lock
YY> before actually starting the build procedure.

Well, I see two problems with this:
1. Agents run on different boxes, so I'd have to come up with some shares
2. The build would have already started by the time it gets to my locking
logic, so the agent would be kept busy instead of serving other build configs.
Haven't thought this through, but I imagine one could also end up with deadlocks
because of this.

If the API allowed some conditional logic to be put in place (where the decision
to start a build is taken, on the server), then I'd probably look into it.
Otherwise, I think I'll wait for the official solution. :)

Best,
Andrei


0

Please sign in to leave a comment.