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
Please sign in to leave a comment.
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.
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
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
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?
> 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.
>> 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.
> 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 createdSeems 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.
Yes, that should be the case.
> 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