TeamCity in Google Chrome

We try things here at JetBrains, so of course we tried Google Chrome on the day it was released. Some of us even switched to Chrome as their main browser.

Apart from just trying the new browser we were also curious whether TeamCity will work OK in Chrome. No surprises here, we did not spot anything broken (since TeamCity works OK in Safari/WebKit).

One of the cool features of Chrome is making web application out of a page and we tried that with TeamCity. It worked out of the box, but we decided to make use of Google Gears API to provide default text for the Create Shortcut dialog and also provide several sizes for the TeamCity favicons so that Chrome can put on the desktop the right size instead of scaling 16x16 default.

Several meta and link tags more and we're in. The latest EAP already has the changes.
If you have it installed, you can get the different-sized icons via URLs:

your_teamcity_server/img/icons/TeamCity16.png
your_teamcity_server/img/icons/TeamCity32.png
your_teamcity_server/img/icons/TeamCity48.png
your_teamcity_server/img/icons/TeamCity128.png
your_teamcity_server/img/icons/TeamCity512.png

Huh? 512? Yes. Just in case someone will need it that big :)

Here is also a related post on DZone.

CITCON Amsterdam 2008

Two of our team: Pavel Sher and Yegor Yarko attended Continuous Integration and Testing Conference (CITCON) whose European meeting was held in Amsterdam this year.

It was the first full-time OpenSpace conference I've attended and it was fun to see how it works. It's really amazing how a non-managed process can work out so well.

It was a pleasure to meet TeamCity users, developers from other CI tools and other insightful people. Here is a small CITCON photo set.

Shall we meet at the next CITCON Europe?

Calcutta EAP, build 7757

On Thursday we've released a new EAP build, but I was a bit in a hurry leaving for a flight to Amsterdam to post the announcement here. But better late then never :)

This build introduces enhancements in the builds dependencies, namely: option to reuse the builds if they have no changes rather then rebuilding them each time for an upstream build; ability to configure artifact dependency to use the dependency built on the same sources; support for the builds sequences in the personal builds and display of the dependencies for a running/finished build.
If you try the feature, let us now how it suits your building process and what is still missing to fulfill your build dependencies requirements.

Other additions in the build are individual test details page with the test runs history and ability to commit a pre-tested commit if no new tests failed.
And yes, we've also added support for .Net code inspections tool: FxCop form Microsoft.

One of the features we started to work on is integration with externals source browsing tools. Some initial functionality is already baked in this EAP release.

Here is how to try it: Create a new file named change-viewers.properties in the .BuildServer/config directory with the content like:

;external change viewers config example
;all entries are optional
;general format is: rootId=external tool link template
*=http://some.tool/view/?changelist=${changeSetId}
;all roots of type 'svn'
svn=http://fisheye/changelog/REPO1/?cs=${changeSetId}
;specific root id
107=http://fisheye/changelog/REPO2/?cs=${changeSetId}

Then look for a link "Open in external change viewer" in the change description on the build's Changes page.
Do you like the feature? What tools do you need integration with?

Browse the full EAP release change log and download the build.

Your comments are welcome!

Calcutta EAP, build 7601

We've just uploaded a new EAP and you can start downloading it :)

The Change Log page pretty much says it all.

A couple of "undocumented" notes, though.

The build has enabled "Agents Statistics Table" tab. Look for one more tab under Agents. It is designed to help TeamCity administrators understand how the load is spread across agents and build configurations.

Actually, the tab was included but turned off for quite a while already. It still needs a lot of polishing, but hopefully we will be able to improve it till the release. Is it helpful? What are your thoughts?

Also, the new search can in fact search for more information that is configured by default. For those of you brave enough, you can try to add test names into the search index by adding -Dtc.search.index.tests=true JVM option to the TeamCity server. If you have many builds/tests and the database is not quick enough, this can cause 100% CPU load for quite a long time after the server start, so use with caution. You can track progress of the indexing on the separate search results page.

As always, your feedback is highly appreciated.

Upgrade button

You probably have seen this illustration before. This is Baron Münchhausen pulling himself and his horse up from the swamp by his own hair. I think this image is the best illustration of our own TeamCity server upgrade process.

What I mean is that TeamCity server we are using at JetBrains to build our projects now is able to upgrade itself... We even have a button in the TeamCity UI which starts the upgrade process. Interested? Well, you can do the same in your testing environment.

First of all we've installed build agent on the same server where TeamCity is running. For security purposes this agent is configured to run one build configuration only (let's call it Upgrade).

Artifact dependencies in the Upgrade configuration were configured to download the artifacts produced by the build that assembles TeamCity installer.

Then we created a build.xml script which unpacks these artifacts, stops the server, backups the previous installation and installs new files. The script is very simple since it is running on the same PC where the server is installed. Finally, the script starts our TeamCity server again. Since all of this is done by the build agent running in a separate process the server can be safely restarted. Agent waits till the server is up again, sends the produced build log and finishes the build.

And now to upgrade our server we just need to click on the "Run" button:



However there is still one significant limitation: we can't choose which build to install. To do that we have to change the build configuration settings (artifact dependencies) every time we want to upgrade, which is not convenient.

Fortunately there is a solution. If you are using TeamCity 4.0 EAP, you are probably aware of the new "Run custom build" feature. Since the last EAP we've improved it a lot. In brief this feature allows you to specify values of build parameters when you click "Run" button. To solve our problem we decided to add one small improvement: we allowed to specify build parameters references in the artifact dependencies build number:



And here is our "Run custom build" dialog where this parameter value can be specified:



Do you remember that TeamCity allows to publish artifacts in parallel with a build itself? This means that in this dialog you can specify build number of a running build too. Think about it, Münchhausen didn't lie...

TeamCity 3.1.2 Release is out

We've uploaded 3.1.2 release on our official download site at jetbrains.com.

This release build number is 6881. We've uploaded 6878 build yesterday, but quickly after that (thanks to one of our attentive users) a problem has been found with connections to Subversion with "svn+ssh" protocol. It turned out we forget to add one of the jars of SVNKit library that we use to access Subversion repositories. A new build with the problem fixed has been uploaded just several minutes ago.

Enjoy!

P.S. If you are already use one of Calcutta EAP builds, just stay tuned. In a week or a bit more we will release a next EAP build with more features included!

Mercurial SCM Support in TeamCity

Among new stable release we prepared another good plugin for you. This plugin adds support for wonderful SCM system - Mercurial. The plugin supports:
* changes collecting
* checkout on server mode
* obtaining files content (allows to view diffs on files)
* checkout rules

Plugin does not support:
* remote run (requires corresponding support in IDE)
* checkout on agent (this feature is in progress)

The plugin works with 3.1.x and 4 EAP releases.

You can get the latest version of the plugin from teamcity.jetbrains.com

There you will find two zip files:
* mercurial-server.zip
* mercurial-src.zip

First zip contains jar files that should be moved to the WEB-INF/lib directory of the TeamCity 3.1.x server. If you need to install plugin under the TeamCity 4.x you can put the whole zip into the .BuildServer/plugins folder. After that restart your server.

Second zip contains full source code of the plugin available under the terms of Apache license 2.0 (you can also obtain source code of the plugin from the mercurial repository: http://hg.jetbrains.org/hg/mercurial/ where it actually reside).

We hope that source code will help us to catch bugs in the plugin faster and will be a good reference for our plugin writers.

Happy building!

Update: Current information on the plugin can be found on the plugin page.