Ability to manage projects/build configurations remotely via API : TW-8394

Back to Search

Project	TeamCity
Priority	Critical
Type	Feature
State	Fixed
Assignee	Yegor Yarko
Subsystem	Server
Affected versions	No Affected versions
Fix versions	Faradi 7.0 EAP (21075), Faradi 7.0 (21241)
Fixed in build	No Fixed in build
Fixed in builds	no build yet

Created by James Strachan
3 years ago (04 Jun 2009 14:55)
Updated by Tony Esposito
8 months ago (19 Mar 2012 18:51)

TW-8394 Ability to manage projects/build configurations remotely via API

Issue is visible to: All Users

The issue is visible to the selected user group only

REST API

Links — Show as list

Relates to:
TW-3287
TW-4124
TW-4846
TW-7999
TW-15900
TW-17801
TW-15166
TW-19802

Is duplicated by:
TW-9277

rest-api_TW-8394_1.zip (2 MB)

Being able to browse/add/update/remove projects and build configurations via HTTP/REST programatically.

Current workarounds:

write TeamCity Java/Groovy/JRuby plugin with full access to object mode via openAPI, expose required API from the plugin
generate necessary XMLs under .BuildServer/config caring about correct structure and unique IDs. See also some related notes in a comment
(for adding new projects and build configurations) create a "template" project or build configuration and then copy it from en external tool emulating user's copy action from the web browser, in line with the notes.

--- original issue text:

e.g. we could then write a script to look for project

myserver/builds/someProject

if it didn't exist we could POST a blob of XML (or JSON - don't care, whatever you prefer) to this URL to create a new project (or PUT to update its settings).

Then we can find the builds for each project again via HTTP/REST and add/remove builds that way.

This would then make it easy for folks to manage the various builds and their configurations using any language/technology.

Some background: We're hosting a ton of projects; we use a Rails application to create them and their resources (JIRA, wik, git repos and so forth). It would be great if we could just do a few HTTP GET/POSTs to setup projects in TeamCity - we could then some well defined templates of builds (e.g. a nightly, checkin and deploy build for each project - the only thing that changes for each project is typically its name and its VCS location)

Comments (48)

History

Linked Issues (?)

Yegor Yarko

23 Jun 2009 22:29

3 years ago

For now this is only possible if a custom plugin is written. We will certainly consider to add this to our REST API, when it becomes available

Related Changes

Type

Bug→ Exception

State

Submitted→ Open

Assignee

<no user>→ Pavel Sher (pavel.sher)

Chris Walquist

14 Dec 2009 21:35

2 years ago

We have about 190 projects and 800 build configurations. Similarly to James' description, developers would like our team to wrap up our company-specific conventions for TeamCity (and related resources) and put it in their hands (we'll probably also do it in Rails). Our deployment system for instance has quite a complete remoting API, but TeamCity is lacking one. A well-designed and highly functional REST api would be a tremendous help.

Yegor Yarko

05 Aug 2010 16:31

2 years ago

A request in the forums: devnet.jetbrains.net/message/5269374#5269374

Anthony Milbourne

08 Sep 2010 20:23

2 years ago

This would also be useful to our organisation. The solution above (directly editing XML config) is not usable as we run a shared instance of the server and could not guarantee that users were not changing config at the same time. It would be great if you could implement an admin API.

Simone Busoli

08 Sep 2010 21:46

2 years ago

Anthony, what do you mean by "shared instance"?

Anthony Milbourne

09 Sep 2010 12:42

2 years ago

We have several teams building projects on that server and each administers their own project(s). Because of timezones and late working it would be awkward to 'close the server' while a script edited the config - not to mention the fact that changes would need to be batched, which would partially defeat the point of an automated system.

Simone Busoli

09 Sep 2010 23:06

2 years ago

Ok I can see what you mean, I thought you were using multiple instances of the server pointing to the same configuration, which left me surprised.

Yegor Yarko

13 Sep 2010 21:00

2 years ago

Anthony,

Can you detail why do you need to do automated changes to the configurations (probably with use cases)?
Can you list the operations that you need most to do remotely?

Anthony Milbourne

13 Sep 2010 21:10

2 years ago

There is only one use case really. When a new project starts up we want to be able to create all the infrastructure in one go, so the subversion repository, the CI project the Issue tracking project, etc. Hence we want an interface that talks to all the different apps and creates the relevant config. So we would like the ability to create a new project (bare minimum), and ideally the ability to create build configurations. Creating and permissioning users would also be a nice-to have - but not so important.

Yegor Yarko

13 Sep 2010 21:45

2 years ago

Anthony,

Thank you for details. It seems that for now you can try to create a project with default settings that you would copy to create a new one.

Anthony Milbourne

14 Sep 2010 12:34

2 years ago

Creating a new project by copying an existing project (or using a template) would be fine. Are you saying that we could do this without an API, or are you confirming that this functionality would be enough if there was an API?

Yegor Yarko

14 Sep 2010 13:11

2 years ago

Anthony,

Most probably you can copy the project now from an external script using "undocumented" way like the one described on the page. The actual URL and parameters can be looked up from the actual request browser sends to the server when you copy a project in UI.
However, since this is an undocumented way, it can be changed in any of the future TeamCity versions without any prior notice.

Anthony Milbourne

14 Sep 2010 13:20

2 years ago

Thanks, we will look at this. However a proper API would be better :-)

Michael Kuzmin

26 Jan 2011 19:44

21 months ago

Also requested in forum thread devnet.jetbrains.net/message/5284371

Michael Kuzmin

10 Feb 2011 17:20

21 months ago

Request in forum to modify build trigger settings: devnet.jetbrains.net/message/5286034

Kevin Conaway

16 Feb 2011 22:46

21 months ago

Any updates here? Having a web service API to create projects and builds would do wonders for our organization

Michael Kuzmin

24 Feb 2011 16:20

21 months ago

request to change VCS roots devnet.jetbrains.net/thread/292893

Stefan Brabec

14 Mar 2011 11:56

20 months ago

For us it would be helpful if SBuildType options (like BT_MAX_RUNNING_BUILDS) could be set via REST. This way we could e.g. customize our build configurations based on the working / non-working hour or weekend (e.g. we would like to trigger 8 long running configurations in parallel during the night but would limit those to 1 or even disable them during office hours). I recently tried the http way of triggering a build with agentId=allEnabledCompatible during midnight, but since BT_MAX_RUNNING_BUILDS is set to 2 it only uses two agents at a time (while all others are idle).

CG ex-Linden

20 May 2011 21:29

18 months ago

Being able to define build configurations via an API would be extremely useful for our organization. We use very standardized combinations of multi-platform builds with snapshot dependencies and also packaging builds aggregated into image builds, themselves aggregated into cluster builds, with very standard artifact dependencies and build completion triggers. Currently, setting up one of these is about a 30 minute exercise of mindless clicking and cutting/pasting. Yes, templates help, and yes, copying projects and configurations help, but you still need to then go through and manually adjust the VCS roots and the dependencies, over and over again.