Build number 8080!
Congratulations, you've just been promoted to the official TeamCity 4.0 release build.
Thursday, November 27, 2008
The most advanced continuous integration for Ruby on Rails with TeamCity 4.0
TeamCity 4.0 has a dedicated rake runner, with support for Rake tasks, Test::Unit, and RSpec tests.
Our special thanks goes to the guys behind RubyMine and Ruby plugin for IntelliJ IDEA, who created this runner for TeamCity.
Here is a short (3.5 min, 7.3Mb) demo of some unique TeamCity's features and how they work for a Ruby on Rails project.
This demo includes:
Our special thanks goes to the guys behind RubyMine and Ruby plugin for IntelliJ IDEA, who created this runner for TeamCity.
Here is a short (3.5 min, 7.3Mb) demo of some unique TeamCity's features and how they work for a Ruby on Rails project.
This demo includes:
- setting up Rake runner build configuration
- running a build, with progress estimate for subsequent builds
- ongoing test reporting while build is running
- viewing changes in version control, which are included into the build (web diff)
- "first failed in"/"already fixed in" features for failed tests
- full sortable test list for a build
- a graph for test duration time
Regards,
KIR
Thursday, November 20, 2008
A chance to try almost TeamCity 4.0 before the official release
We've published build 8018 which is separated from the official release build by only a couple of build number increments.
Don't miss your chance to try it and be fast to let us know if you spot any critical issues with it.
Don't miss your chance to try it and be fast to let us know if you spot any critical issues with it.
Monday, November 3, 2008
How ReSharper found a bug in IDEA with the help of TeamCity
A history of one bug.
Several days ago, I received a message from one of ReSharper developers:
The link opened our internal TeamCity installation with the ReSharper build failed on sources checkout. The error was produced by SVN unable to update a directory:
So ReSharper team can continue their current development effort on performance optimization, but why the directory was not deleted in the first place?
TeamCity uses SVNKit library to talk to Subversion repositories and luckily the developer of the library happened to be just a room away these days. Introduced into the issue he reached for the code to check and soon found a bug in the library that might result in not deleted directory in the working copy. It could only reproduce under certain optimization options that only two products are actually using, one of them being TeamCity and the other ... IntelliJ IDEA. But wait, IDEA is preparing for the 8.0 release these days!
No worries. As I am writing this, the library is already fixed, the latest build downloaded from SVNKit TeamCity installation and as I've just checked on our TeamCity server, the fix is already checked into IDEA release branch.
Actually, the bug is a rare one since it can reproduce only under certain circumstances, it was introduced not so long ago and was only included into EAP releases of IDEA and TeamCity.
Several days ago, I received a message from one of ReSharper developers:
The link opened our internal TeamCity installation with the ReSharper build failed on sources checkout. The error was produced by SVN unable to update a directory:
svn: Failed to add directory 'test/assemblies': a versioned directory of the same name already exists
After some digging it turned out that the directory was deleted from the repository some time ago but was not deleted form the build agent. Then it was added anew and the build failed trying to add a directory that already existed on disk. The workaround was to invoke "Enforce clean checkout" from the TeamCity UI for the build configuration.So ReSharper team can continue their current development effort on performance optimization, but why the directory was not deleted in the first place?
TeamCity uses SVNKit library to talk to Subversion repositories and luckily the developer of the library happened to be just a room away these days. Introduced into the issue he reached for the code to check and soon found a bug in the library that might result in not deleted directory in the working copy. It could only reproduce under certain optimization options that only two products are actually using, one of them being TeamCity and the other ... IntelliJ IDEA. But wait, IDEA is preparing for the 8.0 release these days!
No worries. As I am writing this, the library is already fixed, the latest build downloaded from SVNKit TeamCity installation and as I've just checked on our TeamCity server, the fix is already checked into IDEA release branch.
Actually, the bug is a rare one since it can reproduce only under certain circumstances, it was introduced not so long ago and was only included into EAP releases of IDEA and TeamCity.
Saturday, November 1, 2008
Calcutta EAP, build 7888
A new EAP build was published on Tuesday.
The main changes are described in our EAP space, but there were many others and I will point out some:
As always, your comments are welcome!
The main changes are described in our EAP space, but there were many others and I will point out some:
- Connected agents now display the time of last activity rather then time of registration on the server;
- Presentation of Test Details page has been improved;
- "Triggered by" field of the build now displays the build configuration name if triggered by same-sources dependency;
- Storing of duplicate code finder results has been improved. The results are now valid for all the builds. Previously, the duplicate results were only valid for the most recent build and older builds could show incorrect data;
- If you write a build script or tool and need to detect whether it is run under TeamCity or not, you can now use TEAMCITY_VERSION environment variable that holds TeamCity version as shown in the web UI footer;
- IVY library has been updated. We use it to resolve artifact dependencies on agents. The updated version properly handles spaces in the file names, at last;
- Logging of VCS-related errors into the TeamCity logs has been improved to be less verbose but note more details;
- Windows build agent installer no longer defines JAVA_HOME to point to bundled JRE. This will make the administrators make an explicit choice if their builds use JAVA;
- Build stopping logic has been improved under Windows to eliminate wrong process tree building when process ID was reused by the OS;
As always, your comments are welcome!
Subscribe to:
Posts (Atom)