Requesting builds by revision using REST API

Hi,


I have been working on an app that requests builds using the REST API. Up till now I have been using modification ids to let teamcity know which revision I want the build to be made from. However, as my app needs to request pretty old builds, I often run in to the case where a certain vcs root does not have an associated modification for the revision im interrested in.

So my question is, is there currently any way to request a build using a revision instead of a modificationid?

If not, would it be possible for me to add such a feature? I would be willing to go to great lengths.

Thanks, Bas

6 comments
Comment actions Permalink

Bas,

Sorry for the delay in replying.

Can you please clarify - do you trigger new builds or just querying esiting ones? What requests do you use in the current approch with modificationId ?

If you are triggering builds, then providing revisoins is not yet available in TeamCity, see/vote for the corresponding feature request: TW-5610.
As a workaround and "no guarantees" approach to generate TeamCity changes for a VCS root you can try the one described in TW-8482.

0
Comment actions Permalink

Hi Yegor,

thanks for getting back to me. Let me give you some more background. Im working on automating high level tests. Im making an app that analyzes mercurial checkouts of our branches, triggers builds on teamcity, runs some tests on those builds and does a binary search when a change in output is detected. When my app needs a specific build I query the teamcity database to obtain the appropriate modificationId and trigger a build with

httpAuth/action.html?add2Queue=bt123&modificationId=456


However the workflow at my company results in many revisions without corresponding changes. As I said we use mercurial. We have a branch called trunk, but all the work is done on separate branches and merged into trunk when all tests are green. To accommodate this workflow we have a template teamcity project which we copy for each topic/feature branch. We then edit the vcs root and choose copy, resulting in a new vcs root. Anytime the teamcity project is created after the first push to the new branch we end up with commits that have no corresponding change, at least until they are merged in to trunk.

I have looked at the no guarantees approac, but Im having trouble figuring out which field to change in the database. I could not find a field called current revision or similar. Could you point me in the right direction?

Also, am I correct to assume this only works for vcs roots with 0 changes? I can imagine things go bad when the incremental ids are out of order.

Could this approach be automated? I can imagine a field in the create vcs root ui where a revision can be entered that is used as the first current revision. Ideally this would also work from the edit vcs root ui, so it can be set when creating copies of existing vcs roots.

Would it be possible to create a client plugin that uses an env var to update the checkouts to the revisions I need? I can set env var using the REST API, I would need a way to identify the build when its finished though.

Thanks, Bas

0
Comment actions Permalink

Bas,

Thank you for the detailed description.

You are right, that "no guarantees" approach only works with VCS roots with no changes. It is also at least not trivial to automate this "patching". Complexity here is also in the fact, that the revision that TeamCity operates with is not necessarily the same as visible in the version control.

> I have looked at the no guarantees approac, but Im having trouble  figuring out which field to change in the database. I could not find a  field called current revision or similar. Could you point me in the  right direction?

I'd rather not share this publicly at this time to have some control over who and why needs this. I can send a bit more concrete instructions over email if you like.

> Would it be possible to create a client plugin that uses an env var to  update the checkouts to the revisions I need? I can set env var using  the REST API, I would need a way to identify the build when its finished  though.

This is not possible at this time as TeamCity have changes detection (on server) and checkout revisions coupled at this time. Please vote for TW-5610.

Some general notes:
To understand your case a bit better, can you please describe why do you need an external application to do the tests? Did you consider wrapping this logic inside TeamCity? e.g. run the tests as a TeamCity build that grabs the binaries from other builds via artifact dependnecies. You might write a TeamCity plugin to manage binary search and special triggering of the testing builds.

Also, we are considering adding dedicated support for feature branches which sounds like what you might need. The main idea is start building changes in branches automatically on new branches creation and reuse the same settings as in the main build. Does this sound useful?
If you have ideas on this, can you please describe how would you imagine the feature work?

0
Comment actions Permalink

> I'd rather not share this publicly at this time to have some control  over who and why needs this. I can send a bit more concrete instructions  over email if you like.

Please do.

> This is not possible at this time as TeamCity have changes detection (on  server) and checkout revisions coupled at this time. Please vote for TW-5610.

Done! :)

> Some general notes:
To understand your case a bit better, can  you please describe why do you need an external application to do the  tests? Did you consider wrapping this logic inside TeamCity? e.g. run  the tests as a TeamCity build that grabs the binaries from other builds  via artifact dependnecies. You might write a TeamCity plugin to manage  binary search and special triggering of the testing builds.

We considered it very shortly, but decided it would probably complicate matters more then simplifying them. Im assuming there would be a lot of restrictions, mainly on the tech we can use. Also we dont want to jeopardize the smooth running of our build server with an app that is pretty cpu intensive.

> Also, we are considering adding dedicated support for feature branches  which sounds like what you might need. The main idea is start building  changes in branches automatically on new branches creation and reuse the  same settings as in the main build. Does this sound useful?

If I understand correctly, this would mean no more missing changes, as changes would be collected from the point where a branch is created, not from the point where the vcs root is created. That sounds very useful.

0
Comment actions Permalink

>> I'd rather not share this publicly at this time to have some control  over who and why needs this. I can send a bit more concrete instructions  over email if you like.

> Please do.


Seems like you do not have email filled in the profile here. Please either fill it or send an email to teamcity-feedback at jetbrains.com with a reference to this thread.

> If I understand correctly, this would mean no more missing changes, as changes would be collected from the point where a branch is created, not from the point where the vcs root is created


Yes, that should be the case.

0
Comment actions Permalink

> Seems like you do not have email filled in the profile here.  Please either fill it or send an email to teamcity-feedback at  jetbrains.com with a reference to this thread.

Ah, it was set to hidden, it should be visible now.

Bas

0

Please sign in to leave a comment.