Retrieving changes older then buildtype


Im writing a program that triggers builds on teamcity, downloads them and runs some tests. As vc revisions for a buildtype are not consecutive I need to find out which revisions actually impact a given build type to avoid running lots of identical builds. So I use something like this to build a list of revisions I could trigger:


Using start and count parameters I keep fetching a bunch of changes untill I arrive at the earliest revision the program should check (the "beginrevision" can be specified by the user).

This approach works pretty well untill I noticed teamcity only lists changes for a specific build type if those changes were made after the buildtype was created. This means the program can only go back until the buildtype was created, which is a major limitation.

I can see two workarounds:

-get the revisions from svn using the vc root supplied by teamcity (EDIT: disregard this, as with this approach I would still have to get the change id's to trigger a build)
-get all changes (ie /httpAuth/app/rest/changes) and, for each change, check if any file is located in the vc root (ie /httpAuth/app/rest/changes/id:6307)

Im not really happy about either, as the first would require me write svn specific code and the second would cause a lot of traffic if I have to go back a lot of revisions.

So basically my question is: is there an easy any way to have teamcity list changes older then the specified buildtype?

Thanks, Bas

PS: I just realized the workarounds above wont work. If a trigger a build with a modificationId that corresponds to a change that is older then the buildtype (ie /httpAuth/action.html?add2Queue=bt996&modificationId=6307), the display version (from /httpAuth/app/rest/builds/id:62050) is incorrect. This makes it impossible for the program to determine a requested build was completed. Also the changes url for the old build (ie /httpAuth/app/rest/changes?build=id:62050) lists no changes.



TeamCity detects changes for those VCS roots which are attached to at least one build configuration. So indeed, server is unaware about changes made before the configuration is created. In some cases if VCS root existed and was attached to some other configuration, it is possible to get more changes. Also note, that TeamCity does not import old changes from version control when VCS root is created. Instead only changes committed after the VCS root creation will be taken by TeamCity.

These are limitations that are not easy to fix on our side, because import of changes can be very slow and in fact it is not needed in most of the cases.

It is still not clear for me why do you need to get access to the old changes.


Hi Pavel,

Thanks for responding. You wrote: "It is still not clear for me why do you need to get access to the old  changes." Let me try to explain more clearly what Im trying to do.

Im working on a program that you can instruct to "monitor" a buildtype. You tell the program the buildtype id and the revision you want the program to start monitoring. Lets say the most recent commit is revision 2000, and we tell the program to start monitoring from revision 1000. The program starts by triggering a build at the beginrevision, 1000 in this case. Using the artifacts from that build and simulated input we recorded earlier, we reproduce a user doing some stuff with our program and save screenshots of that reproduced session. Then the program triggers a build for the most recent revision, 2000 in this case. Again it reproduces the session by simulating user input and stores screenshots. The output of both reproduced sessions are compared. If there is a difference the program does a binary search to pinpoint the revision in which the change was introduced. So it will start by triggering a build at 1500 and so on.

My problem is two fold:

- I need a list of changes that impact a given build type, so I know which builds I can trigger.
- I need to be able to trigger and identify builds at revisions older then the build type.

Not being able to set the "beginrevision" to before the buildtype was created is a major limitation, especially since we created some new build types last saturday : )

The first problem I can work around by simply querying all changes regardless of build type and check myself if a changed file is located in the vc root. However this is also not guaranteed to go back far enough.

I have noticed that it is possible to trigger a build with a modificationId that is not in the list of changes for a specific build type, but for me the display version (from /httpAuth/app/rest/builds/id:12345) shows an incorrect number (namely the display version of another build that was completed for that buildtype, one that does include changes made after the buildtype creation). This makes it impossible to trigger a build and identify it when its done, even if I did get a hold of the changeId required to trigger a build. The only way would be to order one build at a time and simply assume that when a build finishes its the one I triggered. This is very shaky as if someone were to trigger a build manually my program would silently use the wrong build.

I hope this makes my desire for accessing old changes more understandable, but Im happy to elaborate further. I appreciate any thoughts you might have on how to deal with these problems.

Perhaps you could elaborate on this some more: "In some cases if VCS root existed and was attached to some other  configuration, it is possible to get more changes." At this point Im open to all ideas : )

Thanks, Bas



Just in case you still have quesstions about this, here are several comment that may make this a bit clearer.

TeamCity only detects changes that go into one of the configured Build Configurations. VCS changes that are not "bound" to any of the build configurations are not retrieved and not stored.

Currently, there is no way to make TeamCity display changes that were committed before a matching build configuration was created in TeamCity.

Please vote for the issue as it seems to cover what you need. However, I am not sure we will be able to implement the feature anytime soon as it would require some major internal architecture change.

Moreover, even if you know a VCS revision, for now you cannot trigger a build in TeamCity for it. See the issue for details.

For now I can only suggest you to implement the checkout logic in a build script so that TeamCity only handles the build triggering, passing the revision that you specify via custom build parameter and all the checkout logic is handled in the build script itself. I am afraid you will need to get the revisoins from the version control without help of TeamCity for now.

These limitations are in fact derived form the main TeamCity goal: run builds. Monitoring VCS is handled in TeamCity but only to the extent of running builds and providing convenient summary to the user.


Please sign in to leave a comment.