Archive for December, 2011

TeamCity 7.0 EAP (build 20939): smart and good looking

Thursday, December 29th, 2011

Right in between Christmas and New Year’s eve we’ve got a shiny surprise for you – new EAP build. It’s going to be hard not to notice the changes in today’s TeamCity EAP build, because we’ve significantly changed user interface aiming to make it more friendly, logical, simple and clear. To begin with, we have redesigned the Administration page to provide faster and easier access to frequently used sections and simplify navigation by grouping settings.

Secondly, it is now very easy to see when a test failed for the first time: you can find this information right above expanded stacktrace:

We decided to get rid of Bulk mode and always show check boxes near test names instead.

In addition to mentioned changes, there are numerous usability improvements: the whole list you can find in the release notes.

However, changed look is not the only noteworthy thing here. In one of the previous EAP builds you could have noticed an experimental feature “Types for build properties”. Since then, it has been greatly improved and now it’s ready to use! The following types are now supported:

  • simple text field with ability to validate its value using regular expression
  • password field
  • check box
  • select control

Note, that if you want to use a typed parameter to introduce a password field in Run custom build dialog, values of password parameters will be hidden from build log and Build Parameters tab of the build, plus values of these parameters can’t be seen in custom build dialog and are stored in scrambled form in configuration files.

As usual, these are only the highlights and there are more to it, so we recommend to take a look at the release notes and give it a try!

Happy New Year and happy building!

TeamCity 6.5.6 bugfix update

Friday, December 9th, 2011

Yet another bug-fix update is out – TeamCity 6.5.6. In this build we fixed issues related to Duplicates Finder (.NET) runner, once again improved general performance and addressed a couple of issues in TeamCity plugin for IntelliJ IDEA platform. You can find the complete list of changes in release notes.

Download the build and share your feedback with us.
Happy building!

Setting up TeamCity as a native NuGet Server

Thursday, December 1st, 2011

TeamCity 7.0 EAP (Early Access Program) was recently opened and one of the new features is the built-in support for NuGet. I recently blogged about setting up TeamCity to pack and publish NuGet packages via a plug-in and this plug-in is now included by default in TeamCity 7. However, the real new interesting feature is that TeamCity is now a native NuGet repository too!

Native NuGet Server?

Many of those that have been using NuGet, have most likely been using it to consume packages from nuget.org where there are currently over 3800 unique packages, most of which are open source.

image

What happens however if for some reason or another you do not want to submit packages to nuget.org? For instance, think that you want to use NuGet to modularize and distribute code inside your own organization, or create libraries for private consumption. In this case, publishing to nuget.org does not make sense. This leaves you with basically two options:

  1. Setup your own NuGet repository by downloading and installing the code that nuget.org for instance
  2. Copy nuget packages to a local share and have everyone read off of that

Both of these options come with their own share of overhead. With the local share you now require sharing of folders and permissions. Setting up your own NuGet repository also requires managing permissions and whatnot separately. At the end of the day, its another service to manage.

Fortunately, you now have a third option: TeamCity. The same server that builds your projects, runs your tests, packs and publishes your packages can now also serve them. The best part of it is that it is so simple, that I had to take up the rest of this blog with the previous nonsense just to give it some meat.

Enabling TeamCity as a NuGet Server

I am not going to cover how to pack and publish packages in this post. All that is covered in detail in the previous post I wrote, so please read that first if you’re not familiar with the process. Enabling TeamCity as NuGet and making packages available consists of two steps:

1. Enable the server to be a NuGet server

Go to Administration | Server Configuration | NuGet tab

image

Click on the Enable button to enable it. The same screen with then display two different feeds: a public and a private one:

image

If by chance the Public Url is not available, you will probably see a message telling you that you need to enable the Guest account in TeamCity, which can be done from the General tab.

2. Make your packages be your Artifacts

Since TeamCity itself is going to be a NuGet server, the step to publish a package is no longer required. However, packing the package is. In this step (NuGet Pack Build Type), we can just configure the output for the package to point to some specific folder, for instance packages

image

We need instruct TeamCity to ouput the results of this folder as artifacts. This is done in the General Settings step of the Build Configuration

image

and with that, we’re done. Next up is to configure Visual Studio to consume from this feed.

Configuring Visual Studio

Although this step is optional, it is recommended to add your repositories to Visual Studio to avoid having to type long URL’s in each time you want to read from a specific package repository. To do this, click on Options | Library Package Manager | Package Manager Settings

image

We need to add a new NuGet Repository. I’ve called it Local TeamCity and the URL corresponds to the public URL provided to me by TeamCity in Step 1:

image

Notice that I have another entry which is Local TeamCity Auth which corresponds to the authenticated version.

Once we have this, we can now easily consume packages from our repository by merely specifying it in the Package Manager Console, either via the Combobox or explicitly in each call:

image

Summary

That’s all there is to it. By merely publishing our packages as artifacts, TeamCity now provides a full-fledged nuget server which opens up great possibilities when it comes to working and managing dependencies between projects. TeamCity is currently in EAP and much of what I’ve described here is in open to improvements. That is why your feedback is very important. Download 7 and start playing with it today. Let us know what you think.