API Improvement

Hi all,

I've recently created a new teamcity server and have built a little .net app which given a name of a branch in VCS and a list of names of modules, it will send off various api calls to create a series of teamcity projects and builds.

This app makes the following calls in order to do the above.

- Create a parent project to represent the branch of code
- Create a sub-project for a given module
- Create an appropriate vcs root
- Create a build configuration
- Pause the build configuration
- Create build step to "build and test" the module
- Create nunit build feature
- Create VCS trigger
- Create build parameters
- Create build setting to ensure a clean build
- Create build setting to set build number
- Create build setting for artifact rules
- Create build agent requirement
- Unpause build configuration
- Add build to queue

This process is nice as all our builds get generated in a repeatable, automated way.  If we wish to tweak builds, we adjust scripts and regenerate builds.

This does produce the builds we're expecting but the problem we have is around 200 builds with each build requiring 15 api calls takes a long time, if we have 1000+ builds already in teamcity.

Is there any way I can combine any of the above calls together as I know there isn't a POST on the project level containing all the above settings?

Comment actions Permalink

Hi Simon,

If your build configurations are alike, I'd suggest to create one and then use copy/adjust logic instead of creating everything from scratch.

There is a related feature request: http://youtrack.jetbrains.com/issue/TW-32877
I will look into it, so it might be available in 8.1.
At this point I am not sure about single request for a project with all the build configurations, seems a bit too much.

BTW, you can try to reuse authentication cookies, that might improve performance of the REST calls (I would appreciate a comment into the issue if it speeds the things up)

Comment actions Permalink

I'll try the cookie now to see if there is improvement

Comment actions Permalink

Hi. I'm unable to get this to work. i receive 401s.

I make a requerst to /httpauth/rest/app/version. the response give me two cookies.  a remember me cookie and TCSESSIONID=690DE6D3A69300D550B760220D00A47B

I create a new request to https://builds/httpAuth/app/rest/projects/_Root including that tcsessionid cookie, and i receive a 401, with the body...

"Authorization" header is not specified
To login manually go to "/login.html" page

The raw request headers i'm sending are:

Content-Type: application/xml
Cookie: TCSESSIONID=690DE6D3A69300D550B760220D00A47B

So to get a 200, and not a 401 when I include the Authorisation header but I see zero difference in speed.

I presume the api checks for the authorization header, but then only uses that header for full authentication if no session cookie present, thus saving some time?

If the above is correct, then i see no performance improvement in api requests.
Comment actions Permalink


Please use another URL for the first request (as /app/rest/version does not require authentication).
Also, please do not use "httpAuth/" URL path as well as send no username/ppasword for the requests with TCSESSIONID cookie.

Comment actions Permalink

Hi Yegor.

Thanks for this.  I used /version because i saw it was a light-weight call.  I've changed it to (/httpAuth/app/rest/users). This call takes 0.04 seconds "overall-elapsed" in reported by fiddler

Then I get the session id from response cookie

I now make a subsequent call to (/app/rest/users) NOT USING session, but using basic authorization and its taking about 0.02 seconds to process.

I now make a subsequent call to (/app/rest/users) WITH session id in header, and its taking about 0.004 seconds to process, so much better.

If any combined api calls are implemented in 8.1, i'd love to know.

Many thanks Yegor!

Comment actions Permalink


> If any combined api calls are implemented in 8.1, i'd love to know.

Please watch the feature request to be notified on updates. Not sure there will be other improvements in the area, but if any, they might be linked with this one.

Comment actions Permalink


I'm finding that the calls made using the session id don't keep the session alive.  after 5 minutes or so, the calls begin to fail.  Is this expected?  For now, i've broken down our calls into batches that should complete in less than 5 minutes.

Any thoughts? Is what I said correct?

Thanks again for all your help.

Comment actions Permalink

To add. I'm having to switch back to including the authorization header in every request as i cant rely a session id lasting long enough. do i have to include something in the header to ask the session to work on a sliding expiration?


Please sign in to leave a comment.