Return all projects and buildTypes with single rest api call
I love this API! But I have a nested hierarchy of Projects, sub-projects, and build configurations. If I make a call like
http://server.url.com/app/rest/projects/id:Foo_Project
I will get a Project object with a buildTypes node representing the build configurations and a Projects node containing the sub-projects underneath the Foo project.
With this approach I would have to iteratively call http://server.url.com/app/rest/projects/id:Sub_Project_1..n,to get the build configurations for those projects, which could conceivably contain more sub-projects, and so on.
My question then, is there a call I'm not seeing that will return all the nested projects and build configurations under Foo_Project? Barring that is there an accepted approach for doing something like this?
Thanks,
Joel
Please sign in to leave a comment.
Hi,
I'm afraid this isn't currently possible. For basic nesting, you can gather the information directly by using the "fields" parameter, the fields aren't expanded by default, but if you specify existing subfields, they will be displayed.
For deep nesting, there are two possibilities: Run through them iteratively, or request a list of all the projects and build your own structure out of them.
Thanks Denis, I'll see how far I can get with the fields parameter.
I know this is a year late, but I interpret the OP as asking if it is possible with a single call to return all buildtyypes contained within a complex nested project (implies this single API call must be using recursion).
If my interpretation is correct then one can use the
Build Configuration Locator https://confluence.jetbrains.com/display/TCD10/REST+API#RESTAPI-BuildLocator
For example:
my.teamcity.com/app/rest/buildTypes?locator=affectedProject:{RootProjectName}
This returns the buildTypes for the root project and ALL nested projects
Hi Matthew,
that would be accurate if the OP was asking about build configurations only, but he also wanted to get the projects, so your call would be missing a good part of what they were asking, according to what I understood, otherwise you would be correct. I would agree that I should have mentioned that as well as it's quite a common scenario, but I definitely read the request as explicitly wanting to contain the project objects as well, so locked in onto that.
Thanks Matthew/Denis. When I can, I will compare what I ended up implementing to the call Matthew suggests and see how it might be used. It does seem to have a lot of the info I need but as Matthew suggests it might be tough to reconstruct the project hierarchy. I will report back.
Thanks again for the additional feedback.
Joel
Thanks, Matthew Copeland The API which you have provided will reduce a lot of logic in our existing application.
Thank you, Matthew Copeland for the answer!