Custom Build Queue Sort

Build queue order can be changed programmatically with help of BuildQueue::applyOrder() method. This method accepts queue builds ids in the new order. However it is better to change order from the separate thread, not from the listener method because changing of the order in turn produces another event: buildQueueOrderChanged. I would suggest to use Java 1.5 single thread executor service (Executors.newSingleThreadExecutor()) and in the listener method submit task to reorder queue to this exector.

The listener methods are not synchronized.

--
Pavel Sher

Ok, I will start working on that and see what I can do. Thank you for the information.

Is it generally a good idea to do any changes in a separate thread from the thread that invoked the listener method? For example, I do a removeFromQueue on the SQueuedBuild passed to buildTypeAddedToQueue if it's a continuous build and continuous builds are disabled. Should this be done in a separate thread?

Yes, until your listener method makes some trivial tasks or modifies its internal state only. I think the general rule could be the following: do not do time consuming tasks or tasks which change TeamCity data model, and since you actually do not know how long does it take to remove build from the queue (in fact, this operation is not quite simple, because among other things it involves persisting of the queue in database) it is better to make it in the separate thread.

--
Pavel Sher

Is it possible that the build will have been dequeued and started running before the separate thread is executed and it is removed? In the case of removing the queued build, I do need to make sure that the build is removed and not executed. Or is there a better way to do this?

I should mention that I want to keep the automatic/continuous builds from executing if they are currently disabled. If it is possible to keep them from ever entering the queue in the first place, that would be also work.

This is possible, but should happen rarely. If you need to disable automatic triggering of the builds you can pause build configuration temporary (this will disable automatic triggering). See SBuildType::setPaused() method. This approach should be much simpler. This action also available from the web UI.

As a side effect pausing of the build configuration will remove all builds of this build configuration currently staying in the queue.

--
Pavel Sher

Oh, fantastic! I can run through the build configurations and disable/enable any automatically triggered builds. I actually had a request to remove any existing builds from the queue when the continuous builds are disabled and this accomplishes that goal as well. The only downside is that you couldn't trigger the build manually, but that's a very minor thing and probably unnecessary.

Thank you.

Actually manual build triggering is enabled for paused build configurations too, only automatic triggering is disabled.

--
Pavel Sher

I just read that in the documentation for setPaused. Is there anything TeamCity can not do?

Well, you know we have a lot of feature requests... Feel free to submit them to our tracker: http://jetbrains.net/tracker/workspace/TW

--
Pavel Sher

That was really a rhetorical question. There are always improvements that can be made to any software. We have been very happy with TeamCity here and are looking forward to future releases/updates.

How would I determine if a build configuration has a VCS trigger setup? I see SBuildType.getBuildTriggers(). Does this also include the schedule/dependency/other triggers as well? I can't find a VcsTrigger interface or class, but I may have missed it.

Never mind. I found jetbrains.buildServer.buildTriggers.vcs.VcsTrigger in server.jar.