Batch add of projects Follow

+1

it would be nice to have some actions be applyable on multiple projects,
e.g. select 10 projects from the build queue and remove them at once.
Or edit the artifacts pathes for 15 branches of the same project at once.

You get "clickeritis" with TeamCity currently ;)

Michael Damberger wrote:

+1

it would be nice to have some actions be applyable on multiple projects,
e.g. select 10 projects from the build queue and remove them at once.
Or edit the artifacts pathes for 15 branches of the same project at once.

You get "clickeritis" with TeamCity currently ;)

I assume the IDEA plugin is using some form of API to Team City - is
this public/documented/exploitable maybe?

This could of course be a nice project to explore the remoting possibilities of TeamCity to add projects, but I'm full up with work as it is, I'm afraid :-/

Anybody else fancy having a try on it??!


Regards,
Stig Kleppe-Jørgensen

I suddenly found myself with just a little bit time free to do some thinkering with this.

There is indeed an XML-RPC remoting API for the server, an example is shown below:

:", );
	session.setCredentials("", "");
	session.authenticate();

	// Retrieve a client that works with the authenticated session
	XmlRpcClient client = session.getClient();

	Vector params = new Vector();
	params.add(Boolean.TRUE);

	// This makes the following call on the server side: XmlRpcBasedRemoteServer.getRegisteredProjects(true)
	System.out.println("return = " + client.execute("RemoteBuildServer2.getRegisteredProjects", params));
]]>

Some more documentation on this topic from the forum below, although the first 2 threads are quite old:

Documentation on how to remotely trigger builds (Sep. 15, 2006):
http://intellij.net/forums/thread.jspa?messageID=5159057

Help using the TeamCity API to remotely manage builds (Okt. 24, 2006):
http://intellij.net/forums/thread.jspa?messageID=5172664

Team City API (May 26, 2007):
http://intellij.net/forums/thread.jspa?messageID=5188771

As it is said in the last thread, the functionality for creating a new build configuration remotely is not available now, but it shouldn't be to difficult adding this ourselves.

This will mean developing our own server side plugin which exports this functionality through XML-RPC by registering it with the XmlRpcHandlerManager.

More information about developing server side plugins:
http://www.jetbrains.net/confluence/display/TW/Plugin+Development

Stig,

Your approach to creating new projects is valid: they can be created just by adding properly-structured XML files under corresponding directory in .BuildServer/config.

The problem with "Checking changes..." seems to be another story. Most probably, all the projects created begun to query the version control and this was just too much at the same time.

The EAP version of TeamCity ( http://www.jetbrains.net/confluence/display/TW/TeamCityEAP%28Latest%29 ) addresses this case by providing ability to assign came VCS roots to different build configurations, thus reducing the number of VCS queries. The source directories under the common VCS root used by each build configuration can be configured through "checkout rules".

If using EAP version is not what you'd want, you can increase VCS query interval (see modification.check.interval on http://www.jetbrains.net/confluence/display/TCD/SystemPropertiesforRunningthe+Server ) and in case this does not help, submit a Jira issue so that we can investigate the problem.

--
Best regards,

Yegor Yarko
Quality Assurance Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

Hello,

Just a couple of notes about our XML-RPC API. First of all existing XML-RPC
API (I mean XmlRpcBasedRemoteServer) should not be considered as complete or
as open API just because it was not designed in this way. So registering of
your own XmlRpcHandlerManager and exposing your own API required by your
plugin is more preferable.

At the same time on the client side, you can safely use XmlRpcTarget for
communicating with server.

SessionXmlRpcTarget differs in the way that it works within authenticated
session. This means that if credentials are correct it will obtain
authenticated session from the server side. This also means that server side
(i.e. XML-RPC handler) should check that session is not expired for every
remote call. Unfortunately we did not expose classes implementing such
behaviour in open API (but we probably will do this in the future).

If you like to write a plugin which will expose some functionality of
TeamCity via XML RPC I think you should use XmlRpcTarget on the client side
and XmlRpcHandlerManager with your handlers on the server side. I think you
can safely avoid authentication part at the moment. Then when we will move
some classes to open API you will be able to easily wrap your XML-RPC
communication within some authenticated session.

Hope this helps.

--
Pavel Sher
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"



"Stig Kleppe-Jorgensen" <no_reply@jetbrains.com> wrote in message
news:10593944.1187179045866.JavaMail.itn@is.intellij.net...
>I suddenly found myself with just a little bit time free to do some
>thinkering with this.
>

There is indeed an XML-RPC remoting API for the server, an example is
shown below:

>

 // Authenticate your access to the server
> SessionXmlRpcTargetImpl session = new 
> SessionXmlRpcTargetImpl("http://:", 
> );
> session.setCredentials("", "");
> session.authenticate();
>
> // Retrieve a client that works with the authenticated session
> XmlRpcClient client = session.getClient();
>
> Vector params = new Vector();
> params.add(Boolean.TRUE);
>
> // This makes the following call on the server side: 
> XmlRpcBasedRemoteServer.getRegisteredProjects(true)
> System.out.println("return = " + 
> client.execute("RemoteBuildServer2.getRegisteredProjects", params));
> ]]>

>

Some more documentation on this topic from the forum below, although the
first 2 threads are quite old:

>

Documentation on how to remotely trigger builds (Sep. 15, 2006):
http://intellij.net/forums/thread.jspa?messageID=5159057

>

Help using the TeamCity API to remotely manage builds (Okt. 24, 2006):
http://intellij.net/forums/thread.jspa?messageID=5172664

>

Team City API (May 26, 2007):
http://intellij.net/forums/thread.jspa?messageID=5188771

>

As it is said in the last thread, the functionality for creating a new
build configuration remotely is not available now, but it shouldn't be to
difficult adding this ourselves.

>

This will mean developing our own server side plugin which exports this
functionality through XML-RPC by registering it with the
XmlRpcHandlerManager.

>

More information about developing server side plugins:
http://www.jetbrains.net/confluence/display/TW/Plugin+Development

Hi Yegor,

Being able to add project XML files directly is great! After hanging on "Checking changes" I just renamed the .BuildServer directory as a backup and started over with just a few of the projects. Now all I have to do is move the XML files over from the backup and everything is ok :)

We're having some problems with performance on our installation of Subversion, so that further explains TeamCity hanging on "Checking changes".

A question regarding checking changes: if checking out to agent is chosen in the VCS settings, will the agent to the checking, or is this still done by the server?

And another one on build triggering: We have all projects under the same VCS root, so have only one shared VCS root for all the projects. For each project we define checkout rules like this:

+:/trunk=>]]>.
-:*

When turning on "Enable triggering by VCS check-in" for all projects, it seems that when checking in a file, not just the file's project is added to the queue, but all projects. Is that intentional behaviour? If so I would need to make a VCS root for each project, right?

And I didn't understand what you meant by assigning VCS roots to different build configurations. How can that help me from having TeamCity checking changes on every project at the same time?

By the way, I'm using the EAP :)

Regards,
Stig Kleppe-Jørgensen

Hi Pavel,

Nice to know. Hopefully the Open API will be expanded and better documented soon :)

Do you have any plans of having a plugins repository for TeamCity? I would think there are some plugins out there already. A plugin exposing the Maven reports would be nice to have.

Regards,
Stig Kleppe-Jørgensen

Hi Stig,

>A question regarding checking changes: if checking out to agent is chosen in the VCS settings, will the agent to the checking, or is this still done by the server?

In this case agent does the checkout. Agent-side checkout is similar to running svn update on the agent. Server in this case just determines what sources changes have occurred to show them in UI.

And another one on build triggering: We have all projects under the same VCS root, so have only one shared VCS root for all the projects. For each project we define checkout rules like this:

+:<project>/trunk=>.
-:*

When turning on "Enable triggering by VCS check-in" for all projects, it seems that when checking in a file, not just the file's project is added to the queue, but all projects. Is that intentional behaviour? If so I would need to make a VCS root for each project, right?

You mean that all build configurations are triggered by VCS trigger, but some does not have any changes in the build triggered? This seems to be a bug. Please report it into our Jira. I tried to reproduce it by your description but all worked well: only the build configurations affected were triggered.

BTW, checkout rules does not support wildcards, so proper checkout rules would be:

-:.
+:/trunk=>]]>.

But your rules work the same (current implementation assumes "-:." rule if at least one plus rule is present) The default rules can be discussed in http://www.jetbrains.net/jira/browse/TW-3142

And I didn't understand what you meant by assigning VCS roots to different build configurations. How can that help me from having TeamCity checking changes on every project at the same time?

TeamCity queries each configured VCS root to check for changes. So, if you have several VCS roots configured that refer to the same repository, this will cause TeamCity to check for the same changes several times, thus increasing load on the VCS server. General rule is: if you have one repository and access it with the same credentials/settings - use single VCS root in TeamCity and configure checkout rules to set what directories should be used in each build configuration.

Hope, this helps.

--
Best regards,

Yegor Yarko
Quality Assurance Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"

Hi Yegor,

>> A question regarding checking changes: if checking
>> out to agent is chosen in the VCS settings, will the
>> agent do the checking, or is this still done by the
>> server?

In this case agent does the checkout. Agent-side
checkout is similar to running svn update on the
agent. Server in this case just determines what
sources changes have occurred to show them in UI.

Does this mean that when the server is checking the changes to show them in the UI, the agent has already started building?

>> And another one on build triggering: We have all
>> projects under the same VCS root, so have only one
>> shared VCS root for all the projects. For each
>> project we define checkout rules like this:
>>
>> +:/trunk=>. >> -:* >> >> When turning on "Enable triggering by VCS check-in" >> for all projects, it seems that when checking in a >> file, not just the file's project is added to the >> queue, but all projects. Is that intentional >> behaviour? If so I would need to make a VCS root for >>]]> each project, right?

You mean that all build configurations are triggered
by VCS trigger, but some does not have any changes in
the build triggered? This seems to be a bug. Please
report it into our Jira. I tried to reproduce it by
your description but all worked well: only the build
configurations affected were triggered.

What I can see clearly is that many builds are starting without having any changes showing in the UI at all. This should not happen if the only triggering I've setup is 'Enable triggering by VCS check-in', right?

BTW, checkout rules does not support wildcards, so
proper checkout rules would be:

-:.
+:<project>/trunk=>.

But your rules work the same (current implementation
assumes "-:." rule if at least one plus rule is
present) The default rules can be discussed in
http://www.jetbrains.net/jira/browse/TW-3142

Those seems fine with me. I removed the -:* from our rules to see if that would mean anything for the triggering problem mentioned above, but it didn't.


>> And I didn't understand what you meant by assigning
>> VCS roots to different build configurations. How can
>> that help me from having TeamCity checking changes on
>> every project at the same time?

TeamCity queries each configured VCS root to check
for changes. So, if you have several VCS roots
configured that refer to the same repository, this
will cause TeamCity to check for the same changes
several times, thus increasing load on the VCS
server. General rule is: if you have one repository
and access it with the same credentials/settings -
use single VCS root in TeamCity and configure
checkout rules to set what directories should be used
in each build configuration.

Aah...now I got it :) That is exactly how we have it; 1 single VCS root with all the projects having checkout rules to specify which part of the repository that is "theirs".


Regards,
Stig Kleppe-Jørgensen

Stig,

Does this mean that when the server is checking the changes to show them in the UI, the agent has already started building?

When checkout on agent is used, it works roughly like this:
- server polls version control server to determine new changes, the changes detected are shown as pending;
- if VCS trigger is configured, build is added to the queue on new change detection;
- when the build starts server: 1. passes the latest detected revision to the agent, 2. associates the detected changes till that revision with the build to show changes in the UI;
- agent checks out (updates) the sources to the revision received from the server
- build begins

What I can see clearly is that many builds are starting without having any changes showing in the UI at all.
This should not happen if the only triggering I've setup is 'Enable triggering by VCS check-in', right?

You are right, provided you do not trigger builds manually. The general rule is that if the build has version control in the "Triggered by" field (the field is available in the build results since build 5433), the build should have changes.

--
Best regards,

Yegor Yarko
Quality Assurance Engineer
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"