Posts Tagged ‘Features’

Now we see dead code too!

Thursday, October 13th, 2011

“I see dead code” – .NET developers all over the world know this slogan due to incredible code analysis feature provided by JetBrains ReSharper. One of the most wanted TeamCity features was to have .NET inspections results right on build server. Starting with the latest EAP you have it!

The only thing you need to do to get all the benefits of ReSharper’s analysis right in TeamCity is to add Inspections (.NET) build runner as a build step to your build configuration.

Configuration is quite easy, so let’s just take a look at how the results look when this runner is configured – you can find them at the dedicated “Code Inspections” tab of the build results.

Here we’ve got all the usuall options like exploring overal inspections statistic, opening problematic sources in IDE, viewing inspections description, etc.

Moreover, using this build runner together with another fresh feature – build failure conditions, you can update your builds status based on of inspections results.

What’s next? First of all, in the nearest future it will be possible to share ReSharper inspections settings profile between your team members and use this profile in TeamCity build. More to come, you will be able to ask TeamCity to run custom inspections related to your code base as well.

As always, your comments and feedback are very much welcome. To try it, install TeamCity 7.0 EAP build.

Enjoy!

Fail build on specific log message

Wednesday, October 5th, 2011

Previously described Fail build on metric change feature is not the only new way of controlling build status and detecting build failures. In TeamCity 7.0 we introduce one more useful feature that allows to mark build as failed, in case when certain line is met in build log.

When starting various processes within a build TeamCity monitors their status by inspecting exit code and performing some other tricks. However in some cases providing build exit code is not an easily achievable task while process output can tell us much more details. TeamCity can inspect all lines in build log for some particular text occurrence that indicates build failure: this feature was actively voted in scope of  TW-3917 and some related issues.
The only thing you need to know to configure this feature is what message is an indicator of build failure. Just add new build failure condition on the dedicated page:

Note, that you can instruct TeamCity to look for a line containing or matching a Java Regular Expression regexp text that appears/doesn’t appear during the build. When the condition is set, the interface looks like:

Here’s how a build failure looks when caused by such condition:

The feature is not completed yet, so your comments and feedback are very much welcome. To try it live, install TeamCity 7.0 EAP build, we recommend the next EAP build which is about to be released in the nearest future.

Enjoy!


Changing .NET properties

Friday, October 15th, 2010

As we promised, we continue the configuration parameters story started in the previous post. Today, I’d like to tell you about .NET related properties.
TeamCity .NET plugins provide a bunch of predefined properties indicating that .NET Framework/SDK/Visual Studio/Mono are detected on build agent. Previously you could refer to these properties as to system properties. Now we’ve changed it.

We decided to turn all these properties into configuration parameters, and therefore we’ve converted all refernces to such properties detected in TeamCity to keep builds running. However, it’s not possible to convert references used from a build script. To workaroud the issue you can add system property in build agent configuration or use compatibility mode switch in TeamCity properties:

  • teamcity.dotnet.properties.compatibility.mode with value true
  • dotNetPropertiesCompatibilityMode configuration parameter with value true in a build configuration settings.

Here is the list of changed parameters:

Before Now
system.DotNetFrameworkX.Y DotNetFrameworkX.Y_x86
system.DotNetFrameworkX.Y_Path DotNetFrameworkX.Y_x86_Path
system.DotNetFrameworkX.Y_xZZ DotNetFrameworkX.Y_xZZ
system.DotNetFrameworkX.Y_xZZ_Path DotNetFrameworkX.Y_xZZ_Path
system.DotNetFrameworkSDKX.Y DotNetFrameworkSDKX.Y_x86
system.VS200X VS200X
system.Mono Mono
system.MonoVersion MonoVersion
system.WindowsSDKX.Y WindowsSDKX.Y

Note, there will no longer reported .NET Framework configuration parameters without explicit bitness (i.e. x86 or x64).

TeamCity Visual Studio add-in feat. JetBrains ReSharper

Monday, September 20th, 2010

In the latest TeamCity 6.0 EAP we’ve added new feature to Visual Studio add-in. Now it is tightly integrated with another popular JetBrains product – ReSharper! So if you have both ReSharper 5.0 (or later) and TeamCity add-in installed, you gain the following benefits:

  • From the add-in’s Failed Tests tool window you can navigate to source code of a failed test.
  • From the same tool window, you can re-run tests failed in a TeamCity build locally with ReSharper.

Note, that by “tests” we mean all kinds of tests supported by TeamCity and ReSharper.
Failed Tests tool window

This feature is just the beginning, we plan to greatly improve TeamCity integration with ReSharper, so there’s more features to come. As usual, we’re looking forward to your feedback and all the feature requests are trully appreciated.

Stay tuned!

Tags in TeamCity

Tuesday, March 9th, 2010

As you might know, TeamCity comes with such feature as build tags – do not confuse with supported VCS tags, because that’s an entirely different story. You can assign any number of tags for a single build, and then use them to organize your build history, or quickly navigate to the tagged builds. There is nothing tricky about that, but one might ask himself when these tags can be helpful.

Well, here is an example. Suppose, after some time of developing, your project manager decides, that you’ve finally got a stable build that can be considered a release candidate, or eap. He can mark this build with “EAP” tag, and thus, guys from QA won’t need to search through the whole build history to find the build they should carefully look at. They’ll just need to filter the history by this tag, or simply type “EAP” in the search field.


You can also leave a comment on any build, providing some extra notes about it; and just as with the tags, you can later on search for the build by the comment. Hope, you’ll like it.
Feedback is appreciated as usual.

Opening TeamCity 5.1 EAP

Thursday, February 25th, 2010

We are glad to announce, that we’ve just opened an Early Access Program for TeamCity 5.1.

Here’s the short list of only some of the improvements and features that today’s EAP brings:

  • Customizable email notifications — now you can use FreeMarker templates to create your custom notification messages.
  • Several UI improvements, such as collapsible projects on overview page and the most voted one — the ability to specify time zone, which is handy for geographically dispersed teams.
  • New Current problems tab is added for a project, that shows which tests are currently failing in this project and which configurations are red.
  • Support for .NET 4.0, and not yet released Visual Studio 2010 and TFS 2010.
  • Improved support for .NET test frameworks.
  • Code coverage support for Maven runner.
  • Ability to produce zip and tar.gz artifacts from a bunch of files.
  • IDE integration plugins improved.
  • read more…


View the detailed release notes, download the build and stay tuned — TeamCity 5.1 won’t take long to appear.

By tradition, we remind you to back up your data before upgrade.

Looking forward to your feedback!

Sincerely,
JetBrains TeamCity team.