Extending the Pre-Merge Test Process (No Failed Tests Ever ... Really)

I would like some general information about plug-ins and extending TeamCity as well as its limits specifically about how to extend the "pre-merge testing" concept. If there is anyone who specializes in this, it would be nice to know if any of this is possible.

In short our main goal is to serialize commits but to also automate them so they can run 24/7. Our ideal goal is if the user can simply talk to the CI server and say "here is my txn/branch/view/whatever, please run the tests against it and if they are okay then commit the results to the tip." For this, we would need:

1) Some way of detecting the health of the tip (state machine). Since we would most likely have a post-commit CI server running tests on the latest tag, it would probably be the responsibility of this CI server to run a script which would modify a file on some NFS mount like "health.txt" which would say "good", "bad", "merging", etc.

2) Ability to synchronize the queue with the status of the tip and pause the queue if it is broken. There is no point running pre-merge tests if the tip is broken. It seems like this could be done with a dependent build trigger. That is, have a "check tip status" build configuration which would call an ant target which would poll the contents of the tip's "health.txt" every X minutes until it says "good" and then cause the CI server to trigger the real "run tests" build configuration. This would tie up a build agent, though, so a real way to pause the queue would be better.

3) A plug-in or standalone program that would act much like the IDE plugin. This part would need to talk the VCS and TeamCity. It take the user's changes, update them with the tip, and send them to TeamCity for the tests to be run. If the tests ran successfully, another dependent build configuration would run to change the state machine from "good" to "merging" and send the "OK" back to our plug-in/standalone program which would then merge the results with the tip. Unlike the IDE integration, there would be no user interaction, so it would need to fail if it could not resolve any non-trivial conflicts (next step would be early detection of merge conflicts). Either way, the state machine would change from "merging" to "good" again and the next job in the queue would be processed.

Basically, this would all boil down to a front end application which would feed information to TeamCity. But the question is: how much of this is possible with the plug-in interface?

1 comment
Comment actions Permalink


Honestly, I cannot get what is the exact problem you're trying to solve. It is important for us to understand this clearly, because
it looks like there is really no way to implement such functionality externally, via a plugin (remote run functionality is not a part of OpenAPI).

What's wrong with the current implementation of the pre-tested commit functionality in TeamCity?
Which problems have you experienced? What scenario do you have in mind when you describe your solution?

Kind regards,


Please sign in to leave a comment.