We believe that TeamCity upgrade procedure is one of the less painful among other servers on the market. Usually upgrade of TeamCity to a new version implies conversion of database and configuration files. Until now this activity was not clear to our users, because it performed automatically. As a result users sometimes do not understand what happens and how upgrade works.
We want to make it as explicit and clear as possible. With this EAP we introduce new upgrade process. If newly installed TeamCity decides that data conversion is required, it will ask for confirmation from server administrator and also offer a possibility to make a backup (which we highly recommend in any case).
Note that automatic backup option will be available for if previous version is at least TeamCity 6.0. For TeamCity 5.1 you'll need to make a backup manually.
Manual build configurations selection for an agent
It seems there are two different patterns how our users distribute agents among build configurations. Some of them configure this distribution with help of agent requirements and then TeamCity decides what set of agents can be used to run build configurations. Others want to specify explicitly which configurations can be built on which agents, and do not want to allow building of other configurations on these agents.
When we started developing TeamCity we decided that the first case is more common, but at the same time we allowed the second case too. However, UI for the manual configurations selections for the second case is far from ideal, and quickly becomes very unusable with increasing number of configurations. In TeamCity 6.0 we decided to partially address this problem by providing better and more convenient user interface.
Autocompletion in agent requirements
Agent requirements dialog now has autocompletion enabled. Autocompletion works for both parameter name and parameter value. The whole set of parameters on all of the connected agents is considered, and you can see how many agents have this parameters defined, and with what values.
JetBrains dotCover integration
Jetbrains dotCover is now bundled with TeamCity, and is listed as another coverage engine for .NET runners. Also HTML coverage report for coverage data gathered by dotCover is available.
Gradle integration improvements
Gradle support in TeamCity has got a number of improvements:
- Improved test reporting, including Gradle parallel test execution.
- Gradle Wrapper scripts support. To use wrapper script "gradlew" just set appropriate checkbox on build step configuration page.
- System properties defined in TeamCity are now available in Gradle build. These properties can be accessed via "teamcity" project attribute.
- IntelliJ IDEA coverage engine is now supported for Gradle
Visual Studio Addin
For the past months our main focus for VS addin was performance. We've done several improvements and would like to see your feedback on that matter.
- Startup performance improved
- Local changes collecting performance improved
- Subversion integration reworked
Download patch to IDE
One more link is now available for each change list in the web UI (right now it works for Eclipse plugin only, support for IntelliJ IDEA is coming):
After click on the link IDE automcatically downloads patch from the server:
With help of shelves you can save your changes locally and restore them later:
Re-run failed tests
IntelliJ IDEA plugin and Visual Studio Addin already have feature to re-run locally tests failed on the server. With this EAP this feature is available in Eclipse plugin too:
- Option for snapshot dependency to force running of the build on the same agent where it's dependency built
- Failed tests re-run in IntelliJ IDEA plugin reworked