Teamcity rest extension

Hi guys,



I’m currently working at PSA Peugeot Citroën group, which consider the possibility to use TeamCity as its next continuous integration platform.

We are currently trying to automate the creation of environments in Teamcity for our projects. To do so we use the rest api. I’m developing a rest client based on the jersey client and the Teamcity rest-api (in order to reuse the jaxb binding).


To reach our goal, I had to extend the Teamcity rest api and we want to share this extension with the community.
You can integrate it to the official rest plugin if you wish. This extension contains two parts:

  • It adds the possibility to create a UserGroup. New URL :
    • POST XML <group-ref key='Group Key' name='Group Name'/> to : http://teamcity:8111/httpAuth/app/rest/userGroups/
  • A refactoring of the BuildTypeRef class. Marshaling was ok but unmarshalling wasn’t working. It’s only a refactoring, methods and constructor signature don’t changed.


You will find in attachment a patch file which contains a diff with the 7.0.x branch.

Maybe you want I open an issue for this?

Best regards,

Bertrand FRANCHET



Attachment(s):
patch-tc-rest-api.txt.zip
5 comments
Comment actions Permalink

Hi Bertrand,

Thank you for the patch, we really appreciate your effort.

Can you please explain why do you need BuildTypeRef to support unmarshalling?
Actually, many JAXB-using classes in the current plugin are written in the same way (getters only), so changing only one does not seem to  make much diffeernce so far.

The reason behing this non-bean approach for JAXB classes is that getter-only classes look more structured. Othervise they would require monstrous constructors/init methods.

Also, for many JAXB classes only some of the fields make sence to post (and unmarshal). e.g it seems no sense to post webUrl in BuildTypeRe.

0
Comment actions Permalink

Hi Yegor,



Here are some details.

My rest client retrieves a project (jetbrains.buildServer.server.rest.model.project.Project). Then I would retrieve the buildTypes of this project in order to modify them (Attach vcs-root to each buildTypes). So I do: myProject.buildTypes.buildTypes, which gives me a list of buildTypesRef. But the buildTypeRef retrieved didn’t contained id, name, etc. And I need the id in order to do the vcs-root attachment.

Don't hesitate to ask if you need more details


Best Regards,


Bertrand FRANCHET

0
Comment actions Permalink

Bertrand,

Sorry for the delay in replying.

Actually, request like http://localhost:8111/app/rest/projects/project28/buildTypes returns BuildTypeRefs in the form of:

<buildTypes>
  <buildType id="bt117" name="Build A" href="/app/rest/buildTypes/id:bt117" projectName="Name 1"  projectId="project28" webUrl="http://munit-007:8111/viewType.html?buildTypeId=bt117"/>
  <buildType id="bt118" name="Build B" href="/app/rest/buildTypes/id:bt118" projectName="Name 1"  projectId="project28" webUrl="http://munit-007:8111/viewType.html?buildTypeId=bt118"/>
</buildTypes>

So, seems that it's an issue of your client. It is probably caused by the fact that you reuse REST API JaxB bean classes for it.
Seems, it might be not a good idea to reuse bean between server-side and client-side.

Please let me know if I misunderstand the case or you have other considerations on this.

As to user group creation: I have committed the patch into trunk that will be released as 7.1 with several minor changes and one larger: I changed the bean accepted from <group-ref> to <group>. This also allows specifying user group description. Hope this will not cuase major inconvenience when you upgrade to TeamCity 7.1.

0
Comment actions Permalink

Hi Yegor,


Don't worry for the delay.

Indeed problem come from the fact I reuse the REST API JaxB bean classes in my client. (In fact I set the rest-api.jar as a dependency of my client)

We may imagine that you decide a day to provide a java client for the REST API. You will rewrite all JaxB bean classes in this client and do code duplication? For me, share the JaxB bean classes between server side and client is a best design solution.


Moreover, I’m a bit surprised because I found some classes which have the same structure than my modified buildTypesRef. Ex:

  • jetbrains/buildServer/server/rest/model/project/ProjectRef.java
  • jetbrains/buildServer/server/rest/model/change/VcsRootRef.java
  • jetbrains/buildServer/server/rest/model/change/VcsRootInstanceRef.java  

But that’s right, I ask a modification on code which actually work perfectly for you. So I understand your point of view.


No problem on my side to replace <group-ref> by <group>.

Regards,

Bertrand

0
Comment actions Permalink

Thank you for the response.

> For me, share the JaxB bean classes between server side and client is a best

Hmmm. Only if they are interfaces/clear beans. Otherwise client would require server-side object model as a dependency.

You are right, some of the classes are written one way and some another - that is for historic/investigating what is better reasons. But I agree - not very clean and something to fix when the approach to win is identified.

Seems like the client can be generated from application.wadl at some point...

At some point we will provide a REST client and these are all questions to answer at that time.

0

Please sign in to leave a comment.