JetBrains TeamCity Blog

Until today continuous integration for Xcode projects within TeamCity was tedious and error-prone process. All you could do is to configure command line build step in a build configuration, somehow mark agents where Xcode is installed and manually configure agent requirements in build configuration, otherwise your build could go to an agent without Xcode installed and fail. Features like compilation errors recognition and on-the-fly test reporting were not available too.

But today we would like to announce a plugin which should make building Xcode projects much more convenient. The Xcode runner plugin provides dedicated Xcode runner, which brings a lot of goodies:

• user friendly interface
• support for both Xcode 3 and Xcode 4 projects
• automatic on-the-fly reporting of tests started by Xcode build
  
  
  
• automatic detection of Xcode presence on agent
• parsing of Xcode build log and recognition of compilation errors
  
  
  
• hierarchical view for Xcode build log

A couple of notes about user interface. As you can see below, you can select whether you want to build your project with Xcode 3 or Xcode 4. Xcode 3 build is target based, but there is no need to remember exact names of your targets, platforms and SDKs, if you press “Check/Reparse” button, TeamCity will parse Xcode project files and fill in the form with settings from the project, thus making it very easy to configure desired Xcode parameters.

In case of Xcode 4 the process is even simpler, all you need is to specify name of the scheme.

You can download plugin from the plugin page: Xcode runner.
Installation is simple, just put the plugin under <TeamCity data directory>/plugins folder and restart TeamCity server. After that agents will upgrade, and you can start configuring your Xcode build configuration.
The plugin is still in early beta state and can have bugs and usability issues. Feel free to report them to our tracker: http://youtrack.jetbrains.com/issues/TW.
Note that plugin is compatible with TeamCity 7.0, it won’t work with earlier versions.

By the way, as an Objective-C developer you might also be interested to know that JetBrains has recently released a new version of AppCode – a smart IDE for Objective-C developers building native Cocoa apps for MacOS X or iOS with a bunch of new refactorings, enhanced debugger and a lot of other goodies.

Enjoy!

Over the last few weeks we have made a great deal of improvements in .NET inspections support. As a result .NET Inspections (powered by JetBrains ReSharper) and FxCop inspections runners produce much more clear results.

In case you missed, some time ago we announced new .NET inspections runner based on ReSharper inspections engine, and we already received feedback on it. Thanks to our EAP users we were able to fix a number of serious problems:
- LINQ usages are marked as unresolved symbols;
- TW-18724 NUnit attributes usages (and all External Annotations);
- TW-18730 Usages of resources in WPF, Silverlight projects.

Now the updated plug-in is available for download: follow the installation instructions and share your feedback with us.

As for FxCop runner, it now has a new setting – ‘FxCop version’.

It is really useful in case you have several FxCop versions installed in your build farm: selecting the version of FxCop to use in the runner settings will allow to keep the results consistent. If you’re not sure which FxCop versions you have installed, just go to Agents > Parameters Report page and use ’system.FxCopCmdFileVersion’ parameter name. You’ll get something like this.

Updated plug-in is available to download too.

Note that both plugins are compatible with the latest TeamCity 7.0 EAP and are not intended to work with earlier TeamCity versions.

Enjoy!

“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!

After our posts about TeamCity’s new multiple build steps (previously called “multiple build runners“) feature and further changes in .NET build runners, I believe that plugin developers might have some questions to be clarified.

So today, I’m going to shed some light on the major agent-side API changes that we’ve made to support multiple build steps. I hope this post will help you to painlessly improve your build runner plugins.

AgentRunningBuild interface no longer represents parameters for a build runner. We’ve introduced new interface BuildRunnerContext that provides parameters for build runner. Starting with TeamCity 6.0 AgentRunningBuild will only describe a build.

Note that there is no getter for BuildRunnerContext in AgentRunningBuild. AgentLifeCycleListener interface now provides BuildRunnerContext in build step related methods.
We’ve added runnerFinished event and updated almost all build-related events signatures to contain AgentRunningBuild and BuildRunnerContext instances. So, in most cases one will not need to cache those instances in a plugin code.

So if you ask yourself, what to do to improve your build runner, the answer is simple. If your build runner is implemented by extending CommandLineBuildService, you need to extend BuildServiceAdapter abstract class. This class contains all getters for all parameters you may need in build runner implementation.

Of course, this post doesn’t cover all the details, but only gives general tips. So don’t hesitate to ask questions, I’ll be glad to answer.

It’s about time to try a new TeamCity 6.0 EAP build, which introduces the long-awaited feature – Multiple Build Runners. Many of you voted for this one, and now we would like to hear your feedback on it. Here’s how it works – you can add as many build runners to a single build configuration as you need, and they will be executed step by step. In the end, the build gets merged status and the output goes into the same build log. If some step fails, the rest are not executed. We’re still actively develop this feature, so it’s up to you to help us make it better!


In addition to Multiple Build Runners, this EAP build contains various improvements for IntelliJ IDEA Project Runner, IntelliJ IDEA plugin, Eclipse plugin and more. Check the complete release notes and try the build, but don’t forget to back up your data before upgrade.

One more thing, there’s a new open-source plugin you might find interesting – Cloud-VMWare plugin, which provides an implementation of TeamCity cloud support for VMWare Player. Note, that this plugin is designed to work with the most recent TeamCity 6.0 EAP release, meaning this one.
Enjoy!

The JetBrains TeamCity Team