In real world applications we have all too often external dependencies in test cases. Sometimes theses third party are not always available (i.e. remote webservices).

For continuous integration I want check a minimal set of tests but for my local development i want check a maximal set of tests. I want run my tests on command line (via maven) and in eclipse (via testng-plugin).

Here is my idea to do that …

My project super pom defines 2 profiles:

• test-min
  1. active by default
  2. exclude testng groups (online-tests, thirdparty-tests,…)
• test-max
  1. run a defined testng suite
  2. the suite defines a maximal set of test (all testng groups)

<profiles>
  <profile>
    <id>test-min</id>
    <activation>
      <activeByDefault>true</activeByDefault>
    </activation>
    <build>
      <plugins>
        <plugin>
          <artifactId>maven-surefire-plugin</artifactId>
          <inherited>true</inherited>
          <configuration>
            <excludedGroups>${excludedTestGroups}</excludedGroups>
          </configuration>
        </plugin>
      </plugins>
    </build>
  </profile>
  <profile>
    <id>test-max</id>
    <build>
      <plugins>
        <plugin>
          <artifactId>maven-surefire-plugin</artifactId>
          <inherited>true</inherited>
          <configuration>
            <suiteXmlFiles>
              ${basedir}/src/test/resources/Testsuite.xml
            </suiteXmlFiles>
          </configuration>
        </plugin>
      </plugins>
    </build>
  </profile>
</profiles>
<properties>
  <excludedTestGroups>online,integration,thirdparty</excludedTestGroups>
</properties>

Each subproject must define a testng src/test/resources/Testsuite.xml:

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="TestSuite for Foobar">
  <test name="Online Tests">
    <packages>
      <package name="de.foobar.*" />
    </packages>
    <groups>
      <run>
        <include name="online" />
      </run>
    </groups>
  </test>
  <test name="Integration Tests">
    <packages>
      <package name="de.foobar.*" />
    </packages>
    <groups>
      <run>
        <include name="integration" />
      </run>
    </groups>
  </test>
  <test name="Thirdparty Tests">
    <packages>
      <package name="de.foobar.*" />
    </packages>
    <groups>
      <run>
        <include name="thirdparty" />
      </run>
    </groups>
  </test>
  <!-- Each project can define MORE groups: i.e. "interactive" -->
  <test name="Other Tests">
    <packages>
      <package name="de.foobar.*" />
    </packages>
    <groups>
      <run>
        <exclude name="online" />
        <exclude name="integration" />
        <exclude name="thirdparty" />
        <!-- Each project can define MORE groups: i.e. "interactive" -->
      </run>
    </groups>
  </test>
</suite>

If the sub project defines more exclude groups (i.e. a additional “interactive” group) then the pom must overwrite the excludedTestGroups property:

<properties>
  <excludedTestGroups>online,integration,thirdparty,interactive</excludedTestGroups>
</properties>

To check the correct configuration of the two profiles we can use help:effective-pom:

mvn -Ptest-min help:effective-pom | less

<plugin>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <excludedGroups>online,integration,thirdparty,interactive</excludedGroups>
  </configuration>
</plugin>

mvn -Ptest-max help:effective-pom | less

<plugin>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <suiteXmlFiles>
      <suiteXmlFile>d:\foobar\src/test/resources/Testsuite.xml</suiteXmlFile>
    </suiteXmlFiles>
  </configuration>
</plugin>

Now I can run min/max tests for each project which depend on the above super-pom. The test-min is the default profile and would be used on the continuous integration system (i.e. TeamCity).

Try it

At work, we’ve just started using TeamCity as our continuous integration server. The app itself is very slick, but the documentation is spotty. There doesn’t seem to be a simple example of how to set up TeamCity 4.5.x with subversion anywhere on their site (or on the net either, although they’re probably hidden away inside nabble or something). Happily, I can remedy this.

Setting up a VCS Root

You’ll need to set up a new VCS root for each project. Let’s say we’re setting up SVN for a project called unstableterrain. Setting up the project itself is simple, so I’ll assume you’re up to the challenge.

For the sake of brevity, let’s imagine the subversion repository is set up like so:

root
  |---- trunk
  |---- branches
  |      |---- ...
  |      |---- v04.02.00b
  |      |---- v04.02.01b
  |      |---- v04.02.02b
  |      |---- v04.03.00b
  |      \---- ...
  \----tags
         |---- v04.02.00.1
         |---- v04.02.00.2
         |---- ...
         \---- v04.03.00.266

So, onto the instructions.

1. Add a VCS root:
   • name = ‘unstableterrain via SVN’
   • type = Subversion
   • URL = http://my.svn.server:9001/svn/unstableterrain/
   • set your username and password accordingly (if your svn server allows anonymous checkouts and your build script doesn’t check anything in, then you can skip this entirely)
   • Labelling rules: Add trunk, and a rule for every branch you plan on using. This, unfortunately, is manual in the version I’m using (4.5) because wildcards don’t work. In this example, you’d enter

     +:trunk=>tags

     +:branches/v04.02.00b=>tags

     +:branches/v04.02.01b=>tags

     +:branches/v04.02.02b=>tags

     +:branches/v04.03.00b=>tags

     … you get the idea

   • Test the connection
   • Save; you’re done.

Attaching your VCS root to a project configuration

Say we’re setting up a project config called “unstableterrain v04.03.00 snapshot”. You want to check out this branch and run builds against it, incrementing the build label and tagging.

1. Add general details
   • build number format = v04.03.00.{0}
   • Artifact paths: these map from the results of your build to directories under the artifacts node, e.g.:

     build/dist/*.war => dist

     build/emma/all/**/*.html => emma

     build/tmp/checkstyle/**/*.html => checkstyle

2. Add VCS settings
   • Attach the existing VCS root you specified earler (i.e. ‘unstableterrain via SVN’)
   • Edit checkout rules on the VCS, since we want to tell SVN which branch to checkout for this configuration:

     +:branches/v04.03.00b/=>.

   • VCS checkout mode = automatically on agent
   • VCS Labelling mode = Successful only
   • VCS Labelling pattern = v04.03.00.%system.build.number%
   • Choose VCS roots to label: ‘unstableterrain via SVN’ VCS root
3. Edit build runner
   • add your settings
4. Build Triggering
   • add your settings
5. Save

And that’s it.

This was an interview question for me two jobs ago: “Have you heard of Continuous Integration?” – my answer was “No sir, but the project I worked on was a large scale integration effort and I have been involved in some serious technology & team integrations rather continuously – is that close enough?”.

The interviewer said – “no, that’s not that, if you haven’t heard of it then you should look into it”.

And now – two jobs later. I have been involved in setting up some form of CI process for my current and past two projects. I have to say, I’m a big fan of the whole processes now. I can’t imagine any projects these days running without some sort of CI

Here’s the definition by Martin Fowler the UML guru:

Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily – leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly. This article is a quick overview of Continuous Integration summarizing the technique and its current usage.

(If your project doesn’t have a CI you should seriously consider adding it. It’ll keep your code cleaner, your product much better. More than that, it’ll make your life and the life of every one involved in the project so much easier.)

I have worked with a couple of products so far – JetBrain’s TeamCity and Hudson.

Hudson is completely free – it’s simple & straight forward. Easy to manage configurations, and the whole concept is rather simple. Very easy to get it up and running in no time. Team City on the other hand is from JetBrains. I have heard intelliJ from JetBrains is the best IDE in the world, but I haven’t had a chance to play with it yet. I can’t speak for intelliJ, but I can really speak for TeamCity.

TeamCity is just awesome. The product description goes like this “Distributed Build Management and Continuous Integration Server” (we techies love all things distributed, yes). The product comes with a free and commercial version, the free version supports 3 build agents (for distributed builds) and 20 users. For small teams this is good enough.

The best part about TeamCity is it’s Eclipse plugin and the RemoteRun feature. The plugin lets you select a subset of files you have updated since your last checkout and submit them for a remote build run – the server “does a fresh checkout of the entire code base, overwrites the files you submitted and runs through the compile/test, etc”. And all the while you could be watching the live server logs in your Eclipse plugin – life can’t get any better than this.

I am using Hudson now and I like it so far. One small limitation – it doesn’t let me checkout two projects from two different branches. The only way of doing this is through two separate projects one lined up after another, or use command line checkout using the “Execute shell” option. The documentation says Hudson is also a Distributed server, but I haven’t configured Build agents so I can’t speak for it. Any one has any experience on this?

Anyways….. Go Continuous Integration….

Hi all, it’s been a few weeks and there’s been quite a lot going on chez Harrington.

My last day at uSwitch has come and gone and I found it harder to leave than I thought I would. They have an amazing group of developers and managers and it’s still a fantastic place to work but ulitmately I think it was time for me to move on. Incidentally, for anyone reading this, if you get an opportunity to work there then grab it with both hands!

So I’ve had some time off as I don’t start with my new company for another 10 days (after a well deserved holiday in Lanzarote) but I did want to catch up with them before I went away so I headed over to their offices for an afternoon this week.

My first impressions of the company, team and general set up was excellent – a friendly bunch who clearly want to make their software great. The developers working there seem like good guys, skilled and eager to pick up Agile practices and processes and I’m really excited about seeing how far we can take Agile.

So where will I start?

Well, I’m not going to give my entire game plan away (gotta keep the reader interested for future instalments) but I’ve got a whole barrel load of ideas around Subversion branching strategies, TDD (test driven development), BDD (behaviour driven development) and of course continuous integration.

Of these I think (and it’s an opinion shared by a lot of my colleagues) continuous integration is the obvious starting point when trying to make any shift towards agile. Because once you’ve got it installed and running, you’re always aware of when your build breaks due to subversion merging issues. And once you start to introduce unit tests, you’ll get real time feedback if you’ve broken any logic in your code. This is the foundation you need in order to have confidence in your system moving forward, allowing you to continue to work and refactor as you need.

So we’ve ordered TeamCity for our build server and I’m planning on learning more about Rake as our build language as it is clearly more flexible than NAnt and I’d like more of a chance to learn Ruby. On a side note we’ve also ordered ReSharper as our refactoring tool (because Visual Studio is essentially unusable without it).

All in all, I’m confident these tiny changes will give us the start we need to take our first steps down the agile road. There’s a lot more we can do but as the cliché goes, I’m not going to try and run before we can walk.

I’ll keep you updated on how we’re getting on.

Until next time

So you are working on a large project, many developers committing regularly to the same code base, you run all the unit tests, commit and you break the build. Now everyone on your team is angry (As they should be!). How could this have happened when you ran all of the tests? The reason is that you did not update before running tests locally and committing. The problem is that constantly updating and building can waste a lot of time. Even if you do update, run all tests, then commit, there is still a chance another developer made a commit during that cycle. The solution: Team City Personal Builds.

Personal Builds

The great people at JetBrains have a feature in TeamCity that allows you to use your build server build agents for “Personal Builds”. More great news is that TeamCity plugins that make use of this interesting TeamCity feature are available for IDEs such as IntelliJ and Visual Studio.

So now when you use your IDE tool with the TeamCity plugin you would use the “Remote Run” option to make your commit. TeamCity will then spin up a personal build, apply your code changes to a fresh checkout of the repository, build, and run all unit tests. If your “Personal Build” passes, your code changes will be committed. Now, here is the great part, if it fails, your code changes will NOT be committed, and you will be notified of the failure.

This feature of TeamCity allows developers to get out of the update, run all tests, and commit cycle and offload some of that work to their TeamCity server.

IntelliJ Plugin Setup

• File->Settings->Plugins
• Click on the “Available” tab
• In the search box enter “TeamCity” (The option JetBrians TeamCity Plugin should show up in the list)
• Right click on the plugin and select “Download and install”
• You should see a TeamCity option on your IntelliJ toolbar
• Enter your TeamCity credentials, setup your notifications

So now, when you commit use TeamCity – > Remote Run rather than using the Version Control menu. You will be notified if your commit is accepted or rejected.

Visual Studio Plugin Setup

To download the Plugin, login to your TeamCity server, go to the “My Settings & Tools” page. You will find a download link for the plugin in the “TeamCity Tools” panel on the righthand side of the page.

by Brian Richardson

Idea: make a plugin for TeamCity integration server that can say after build: “WTF!!! Project XXX build is failed!!!” or “Good job!”.

1. I have writen a small program using Microsoft speech object library on C#:

Open text file and read all text from file aloud:

[CODE language="csharp"]
class Program {
static void Main(string[] args) {
if (args.Length != 1)
throw new InvalidOperationException(“1 pameter”);
var text = File.ReadAllText(args[0]);
var spVoice = new SpVoice();
spVoice.Speak(text, SpeechVoiceSpeakFlags.SVSFPurgeBeforeSpeak);
}
}
[/CODE]

 

2. And I have writen notification plugin:

Notifier class must implement jetbrains.buildServer.notification.Notificator.

Notifier contains:

• notifyBuildStarted – called when build started,
• notifyBuildSuccessful – called when build succeed,
• notifyBuildFailed – called when build failed,
• notifyBuildFailing – called when build failing (for example on 1-st test fail in build),
• notifyBuildProbablyHanging – called if somebody make hang operation in out build.

It’s necessary to prepare artifacts for building plugin. I’m using Maven2 for missing artifact resolving.

User must define output file name (with build result information) and reader program in web form.

Two editable fields are created in constructor:

[CODE language="java"]
public SoundNotificator(NotificatorRegistry notificatorRegistry) throws IOException {
ArrayList<UserPropertyInfo> userProps = new ArrayList<UserPropertyInfo>();
userProps.add(new UserPropertyInfo(_OUTPUT_FILE, _OUTPUT_FILE)); ————text box for outputfile
userProps.add(new UserPropertyInfo(_READER_PROGRAM, _READER_PROGRAM)); —- text box for reader program
notificatorRegistry.register(this, userProps);
< }
[/CODE]

To read values from that text fields I create NotificatorPropertyKey’s and send 2 parametrs to constructor: 1^st – string plugin type, 2^nd – string that are passing into UserPropertyInfo object, when properties are registered in Notificator ctor. And finaly we can run reader app from plugin “Process p = Runtime.getRuntime().exec(executeProgram);”

Notifier full source code:
http://code.google.com/p/soundnotification

I’ve been reading through my Ruby books and came across Rake. Rake is a Ruby build program similar to NAnt or MSBuild but instead of writing XML, you use Ruby instead. Now that opens all sorts of doors, so I thought I’d see if I could get Rake to build a .NET solution and take it from there.

First things first, if you want to do this you will need to download and install Ruby, luckily for us, Rake is included. You will need to reboot after to ensure your PATH is updated.

Now we are ready to rumble. First thing I wanted to try was just compiling a solution – nice and simple. There were a few samples around the interweb, and I soon created the following:

DOT_NET_PATH = "#{ENV["SystemRoot"]}\\Microsoft.NET\\Framework\\v3.5"

SOURCE_PATH = "../src"

CONFIG = "Release"

task :default => ["build:all"]

namespace :build do

    task :all => [:compile]

    desc "Build solution using MSBuild."

    task :compile do

        puts "Compiling Solution..."

        solutions = FileList["#{SOURCE_PATH}/**/*.sln"]

        solutions.each do |solution|

          sh "#{DOT_NET_PATH}/msbuild.exe /p:Configuration=#{CONFIG} #{solution} /t:Rebuild"

        end

    end

end

Save this file as “rakefile.rb” and put it in a folder called “build” which is at the same level as the “src” folder. Then at a command prompt, navigate to the build folder and use the following command:

C:\MyRakeSample\build>rake

It worked!

Inside the Rake file we define the default build task as the :all task that is inside our build namespace. This task currently consists of one task :compile. The :compile task searches the src folder for any solution files and the builds them using MSBuild in release.

That was pretty easy and worked without a hitch. So next, I wanted to list the things I wanted my new build script to do:

1. Get the current SVN revision number
2. Update all AssemblyInfo.cs files with a new version number that contains this SVN rev number
3. Build the solution (as above)
4. Run NUnit tests
5. Create test coverage report
6. Copy all the files that need to be deployed (excluding those that don’t)
7. Zip up these files into a deployment package
8. Integrate as much as possible with TeamCity
9. Should be able to run the same build script locally as well as with TeamCity

It took a little but I got it working. You can see the full file here. Below is a breakdown of each section:

Getting the current SVN revision number

First off, you’ll need to get the SVN command line client downloaded and installed. You will need to reboot after to ensure your PATH is updated.

I decided to add a new :init task that should clean up, create folders and get the SVN HEAD revision number. So here is the new code I’ve added:

require 'rexml/document'

....

OUTPUT_PATH = "output"

SVN_LOG_PATH = "#{OUTPUT_PATH}/svn_log.xml"

ARTIFACTS_PATH = "#{OUTPUT_PATH}/artifacts"

SVN_URL = "http://aardvark-cms.googlecode.com/svn/trunk/"

VERSION_MAJOR_MINOR_BUILD = "0.1.0"

namespace :build do

    task :all => [:init, :compile]

    ....

    desc "Perform the required initial tasks."

    task :init do

        puts "Performing Initialization..."

        puts "Creating folders..."

        Dir.mkdir(OUTPUT_PATH)

        Dir.mkdir(ARTIFACTS_PATH)

        puts "Getting SVN revision number and saving to #{SVN_LOG_PATH}..."

        sh "svn log --xml --revision HEAD #{SVN_URL} > \"#{SVN_LOG_PATH}\""

        log = REXML::Document.new File.new(SVN_LOG_PATH)

        logEntry = log.root.elements["logentry"]

        $svn_revision = logEntry.attributes["revision"]

        $svn_message = logEntry.elements["msg"].text

        VERSION = "#{VERSION_MAJOR_MINOR_BUILD}.#{$svn_revision}"

        puts "Revision #{$svn_revision} found with message: #{$svn_message}"

    end

end

There are a bunch of new constants and I’ve included the an xml parser at the top. Then I’ve added a new task called :init and added it to the :all task before the :compile task.

Inside the :init task we create some folders, then we use the SVN command line tool to request the HEAD revision information from the repository url and save it as xml to the output folder that is inside our build folder.

Once there, we can read the details from this xml file and create a version number for our application.

Updating AssemblyInfo.cs with new version number

Now that we have the SVN revision number and have generated a version number for the current build we need to apply it to our assemblies. We do that by rewriting the AssemblyInfo.cs file for each assembly in our solution. That calls for a new task:

PROJECT_NAME = "Aardvark"

COPYRIGHT = "Copyright 2009 1minus1 Ltd. All rights reserved."

namespace :build do

    task :all => [:init, :writeAssemblyInfo, :compile]

    ....

    desc "Write AssemblyInfo.cs with current svn revision."

    task :writeAssemblyInfo => [:init] do

    puts "Writing AssemblyInfo Files..."

        assemblyInfoFiles = FileList["#{SOURCE_PATH}/**/AssemblyInfo.cs"]

        assemblyInfoFiles.each do |filePath|

            puts "AssemblyInfo file found at: #{filePath}"

            file = File.new(filePath, "w")

            file.puts "//This file was generated by the rakefile.rb build script"

            file.puts "using System.Reflection;"

            file.puts "using System.Runtime.InteropServices;\r\n"

            file.puts "[assembly: AssemblyTitle(\"#{PROJECT_NAME} for .NET 3.5\")]"

            file.puts "[assembly: AssemblyDescription(\"\")]"

            file.puts "[assembly: AssemblyConfiguration(\"\")]"

            file.puts "[assembly: AssemblyCompany(\"\")]"

            file.puts "[assembly: AssemblyProduct(\"#{PROJECT_NAME}\")]"

            file.puts "[assembly: AssemblyCopyright(\"#{COPYRIGHT}\")]"

            file.puts "[assembly: AssemblyTrademark(\"\")]"

            file.puts "[assembly: AssemblyCulture(\"\")]"

            file.puts "[assembly: ComVisible(false)]"

            file.puts "[assembly: AssemblyVersion(\"#{VERSION}\")]"

            file.puts "[assembly: AssemblyFileVersion(\"#{VERSION}\")]"

            file.close

        end

    end

end

This is pretty straightforward, we search for all the AssemblyInfo.cs files and then loop through them overwriting them as we go with a new set of attributes. We’ve defined a couple of new constants at the top to use, but the important thing is the use of the newly generated version number.

We add this new :writeAssemblyInfo task to the :all build task before we compile to ensure that every build will include the correct revision number.

Run NUnit Tests

Now we have built our solution, we need to run the tests. Here we need to do something a bit extra as we want to use the TeamCity NUint runner if it is TeamCity running the build. Otherwise we want to use the normal NUnit console for when we are running the build locally.

TEAMCITY_NUNIT_RUNNER = ENV["teamcity.dotnet.nunitlauncher"]

NUNIT_EXE = "../tools/NUnit/nunit-console.exe"

namespace :build do

    task :all => [:init, :writeAssemblyInfo, :compile, :test]

    ...

    desc "Runs tests with NUnit only (without coverage)."

    task :test => [:compile] do

        puts "Running Tests..."

        tests = FileList["#{SOURCE_PATH}/**/#{CONFIG}/*.Tests.dll"].exclude(/obj\//)

        #Select the correct test runner

        if(TEAMCITY_NUNIT_RUNNER == nil)

            sh "#{NUNIT_EXE} #{tests} /nologo /exclude:Acceptance /xml=#{OUTPUT_PATH}/TestResults.xml"

        else

            sh "#{TEAMCITY_NUNIT_RUNNER} v2.0 x86 NUnit-2.4.6 /category-exclude:Acceptance #{tests}"

        end

    end

end

In this task we first get a list of all the test assemblies based on our naming convention (they end in .Tests.dll) and make sure we exclude any from the obj folders. Then if the TeamCity NUnit runner environment variable is available we use that to run the tests, otherwise, use the NUnit console program that we store in a tools folder. At present we are excluding out WatiN acceptance tests, but more on this later.

Using the TeamCity NUnit runner is important to us as it will ensure that the TeamCity test UI and data are updated correctly.

Create test coverage report

This is where it gets interesting for me. Adding test coverage reports is a good way to ensure that you (or someone else) hasn’t been lazy and written some code without a test first. I don’t think that you should have a fixed percentage that must be covered, be pragmatic.

NCOVER_EXE = "../tools/NCover/NCover.Console.exe"

NCOVER_EXPLORER_EXE = "../tools/NCoverExplorer/NCoverExplorer.Console.exe"

COVERAGE_ASSEMBLIES = "OneMinusOne.Aardvark.Web;OneMinusOne.Aardvark.Framework;OneMinusOne.Aardvark.Entities;OneMinusOne.Aardvark.Core"

task :default => ["build:all"]

namespace :build do

    task :all => [:init, :writeAssemblyInfo, :compile, :test, :coverage]

    ...

    desc "Run tests with NUnit and NCover for coverage. NCoverExplorer is used to format the coverage results into html."

    task :coverage => [:compile] do

        puts "Running Tests with Coverage..."

        tests = FileList["#{SOURCE_PATH}/**/#{CONFIG}/*.Tests.dll"].exclude(/obj\//)

        sh "#{NCOVER_EXE} #{NUNIT_EXE} #{tests} /nologo /exclude:Acceptance /xml=#{OUTPUT_PATH}/TestResults.xml //reg //x #{OUTPUT_PATH}/Coverage.xml //l #{OUTPUT_PATH}/Coverage.log //ea System.CodeDom.Compiler.GeneratedCodeAttribute //a #{COVERAGE_ASSEMBLIES}"

        sh "#{NCOVER_EXPLORER_EXE} #{OUTPUT_PATH}/Coverage.xml /r:ModuleClassFunctionSummary /p:#{PROJECT_NAME} /q /h /so:2 /m:80 /h:#{OUTPUT_PATH}/CoverageReport.html"

    end

end

This is a pretty short task. First we use NCover to profile the code while it’s tests are run, then we use NCover Explorer to generate a nice html report. We’ve stored these two programs in our tools folder so you don’t need them installed and it’s easier to get the build running.

You need to do a few extra things in TeamCity to get this to work and show up on a new tab. Here’s what you need to do:

1. Ensure that the build agent service is logged in as an administrator. Otherwise NCover will not be able to profile the tests and you’ll see the error “Profiler connection not established” in your build log.
2. Add the html report that NCover Explorer generates to your TeamCity artifacts under a folder called Reports.
3. Edit the TeamCity main-config.xml file as shown here to add a tab for your html report.

Create a deployment package

The last thing that I want my Rake build to do is to collect together the files I need to deploy and zip them up for me.

ARTIFACTS_PATH = "#{OUTPUT_PATH}/artifacts"

WEB_PROJECT_PATH = "../src/OneMinusOne.Aardvark.Web"

ZIP_EXE = "../tools/7Zip/7za.exe"

task :default => ["build:all"]

namespace :build do

    task :all => [:init, :writeAssemblyInfo, :compile, :test, :coverage, :package]

    ...

    desc "Package the required artifacts."

    task :package => [:compile] do

        puts "Preparing package files..."

        Dir.mkdir "#{ARTIFACTS_PATH}/bin"

        FileUtils.cp_r FileList["#{WEB_PROJECT_PATH}/bin/*.dll"], "#{ARTIFACTS_PATH}/bin"

        FileUtils.cp_r "#{WEB_PROJECT_PATH}/Content", "#{ARTIFACTS_PATH}"

        FileUtils.cp_r "#{WEB_PROJECT_PATH}/Views", "#{ARTIFACTS_PATH}"

        FileUtils.cp_r FileList["#{WEB_PROJECT_PATH}/*.aspx"], "#{ARTIFACTS_PATH}"

        FileUtils.cp_r FileList["#{WEB_PROJECT_PATH}/*.asax"], "#{ARTIFACTS_PATH}"

        FileUtils.cp_r FileList["#{WEB_PROJECT_PATH}/*.config"], "#{ARTIFACTS_PATH}"

        delete_svn_folders(ARTIFACTS_PATH)

        puts "Creating zip package"

        zipFolder(ARTIFACTS_PATH, "#{OUTPUT_PATH}/#{PROJECT_NAME}-v#{VERSION}.zip");

    end

    def delete_svn_folders(folder)

        Find.find(folder) do |path|

            if(path =~ /\.svn$/ || path =~ /\_svn$/)

                puts "Deleting: #{path}"

                FileUtils.rm_r path, :force => true

            end

        end

    end

    def zipFolder(folderPath, zipPath)

        sh "#{ZIP_EXE} a #{zipPath} .\\#{folderPath}\\*"

    end

end

As this is a Castle MonoRail application, I start this new :package task by copying all the required web files to an artifacts folder that is inside the output folder we created earlier. This ensures that we only have the files required to run the application and we exclude all other files.

Once the files are copied I noticed that because we were copying folders, the hidden .svn folders were being copied too. The only way I could see was to then delete these folders from the artifacts folder. This is where the delete_svn_folders function comes in. It just loops through and deletes any path that ends with either .svn or _svn as either can be used.

The final thing is to zip these files up. I use the 7zip command line tool to do this and I’ve added this to the tools folder again to make it as easy as possible to run the build. The zip file is saved to the output folder and is named with the project name and version number.

Finishing up

That’s it really, you can see the full build file here at Google Code. There are some extra bits and pieces in this build like coping the files to the development server, requesting an installer page on the site that will install the database and populate it with data but that was a bit specific for our needs so I didn’t add it here.

The advantage I can see here using Rake over NAnt or MSBuild is that you can program your build using code rather than xml which I find a lot easier and a lot more powerful.

The one thing that is missing from the build is the ability to run our acceptance tests that are written using WatiN. I found this post on Stack Overflow and this post on JetBrains forum which may point me in the right direction.

I hope that has helped, Rake is the future…

Jeremy D. Miller usa como entorno (infraestructura?) de desarrollo: TeamCity + SVN + NUnit + Rake (via)

So you are working on a large project, many developers committing regularly to the same code base, you run all the unit tests, commit and you break the build. Now everyone on your team is angry (As they should be!). How could this have happened when you ran all of the tests? The reason is that you did not update before running tests locally and committing. The problem is that constantly updating and building can waste a lot of time. Even if you do update, run all tests, then commit, there is still a chance another developer made a commit during that cycle. The solution: Team City Personal Builds.

Personal Builds

The great people at JetBrains have a feature in TeamCity that allows you to use your build server build agents for “Personal Builds”. More great news is that TeamCity plugins that make use of this interesting TeamCity feature are available for IDEs such as IntelliJ and Visual Studio.

So now when you use your IDE tool with the TeamCity plugin you would use the “Remote Run” option to make your commit. TeamCity will then spin up a personal build, apply your code changes to a fresh checkout of the repository, build, and run all unit tests. If your “Personal Build” passes, your code changes will be committed. Now, here is the great part, if it fails, your code changes will NOT be committed, and you will be notified of the failure.

This feature of TeamCity allows developers to get out of the update, run all tests, and commit cycle and offload some of that work to their TeamCity server.

IntelliJ Plugin Setup

• File->Settings->Plugins
• Click on the “Available” tab
• In the search box enter “TeamCity” (The option JetBrians TeamCity Plugin should show up in the list)
• Right click on the plugin and select “Download and install”
• You should see a TeamCity option on your IntelliJ toolbar
• Enter your TeamCity credentials, setup your notifications

So now, when you commit use TeamCity – > Remote Run rather than using the Version Control menu. You will be notified if your commit is accepted or rejected.

Visual Studio Plugin Setup

To download the Plugin, login to your TeamCity server, go to the “My Settings & Tools” page. You will find a download link for the plugin in the “TeamCity Tools” panel on the righthand side of the page.

Auto-versioning our assemblies in TeamCity using MSBuild was more fiddly than I expected but ultimately a very clean implementation.

I’m using TeamCity for continuous integration and MSBuild to run our project’s solution file (.sln) as the build script. I wanted each of our builds to have a version number on the assembly (.exe) so that testers would know what they were dealing with. The format for the version number is the familiar dotted quad of Major.Minor.Build.Revision where the Build would be the build number from TeamCity and the Revision would be our version control system (VCS) revision number (our VCS is Perforce).

I use Scrum for Agile software construction, in an OpenUP project management process, so I’ve decided our Major number is the number of the release to the customer and the Minor is the iteration (Sprint) that produced the build. For example, my first build with this system was 0.8.282.11066 which means: we’ve yet to make a release to the customer (0); the build was from the eighth two-week Sprint (8); TeamCity has completed 282 builds; and Perforce is up to revision 11066.

MSBuildCommunityTasks includes an AssemblyInfo task. These are the steps I used to get this working:
(1) added MSBuildCommunityTasks to our “ExternalTools” folder in Perforce and submitted the MSBuild.Community.Tasks.dll and MSBuild.Community.Tasks.Targets files.
(2) integrated the MSBuildCommunityTasks items from step 1 into the solution’s “tools” folder.
(3) updated the MSBuild.Community.Tasks.Targets file to the correct path to the MSBuildCommunityTasksLib (in our “tools” folder from step 2).
(4) imported the Targets file from step 3 into the project file (.csproj).

<MSBuildCommunityTasksTargets>..\tools\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets</MSBuildCommunityTasksTargets>
<Import Project="$(MSBuildCommunityTasksTargets)" />

(5) created the properties for the parts of the version number so it is easy to update for releases and works both on the developer’s machine, where the Build number and Revision number are set to 0, and on TeamCity which provides environment variables for the TeamCity build number and the VCS revision number.

  <PropertyGroup>
    <!-- Release -->
    <Major>0</Major>
    <!-- Iteration -->
    <Minor>9</Minor>
    <Build>0</Build>
    <Build Condition="'$(BUILD_NUMBER)' != ''">$(BUILD_NUMBER)</Build>
    <Revision>0</Revision>
    <Revision Condition="'$(BUILD_VCS_NUMBER)' != ''">$(BUILD_VCS_NUMBER)</Revision>
    <Version>$(Major).$(Minor).$(Build).$(Revision)</Version>
  </PropertyGroup>

(6) deleted the current AssemblyInfo.cs from the source and the VCS.
(6) add the AssemblyInfo task that will autogenerate the AssemblyInfo.cs for each build

  <Target Name="BeforeBuild">
     <AssemblyInfo CodeLanguage="CS" 
                OutputFile="$(MSBuildProjectDirectory)\Properties\AssemblyInfo.cs"
                AssemblyTitle="MyProduct"
                AssemblyDescription="My Product"
                AssemblyConfiguration=""
                AssemblyCompany="MyCompany Ltd"
                AssemblyProduct="MyProduct"
                AssemblyCopyright="Copyright © MyCompany Ltd 2009"
                AssemblyTrademark=""
                ComVisible="false"
                CLSCompliant="true"
                Guid="884276aa-6859-4318-8bb9-073f68a66057"
                AssemblyVersion="$(Version)" />
  </Target>

Now I need to create a WiX project to build a release version and expose it as an artifact in TeamCity so our testers can easily pick up a build themselves.

Technorati Tags: MSBuildCommunityTasks AssemblyInfo TeamCity MSBuild

Version 0.6.13.11 of the tcWebHooks plugin is available for download. It’s mainly a bugfix release and some tidy up of the user interface.

Fixes:
- Fix for newly created WebHooks not being persisted to plugin-settings.xml until re-edited.
- Plugin JSPs loaded using getPluginResourcesPath(), so plugin dir can be anything, and not hard-coded to “webhook”.
- webHookUrl form input style fix for linux (or large fonts in general). URL input field was too wide for div.

Features:
- WebHook blurb updated. A new link can be added to the “Further reading” section of the blurb by adding a <info> line to the <webhooks> section of the main-config.xml
- Enabled events are now listed in Tabs and Edit pages, eg. Build Started, Build Changed Status, Build Interrupted, Build Almost Completed, Build Responsibility Changed

Links:

More Info | Download | Install and usage docs

I welcome any and all feedback.

Good news! Git plugin for TeamCity from JetBrains guys is available at http://www.jetbrains.net/confluence/display/TW/Git. This plugin is much better than 3rd party git plugin for TC. Git Plugin isn’t bundled in TeamCity 4.5, but it is easy to install it. See instructions and documentation at http://www.jetbrains.net/confluence/display/TW/Git

This document assumes you are running the TeamCity package from JetBrains, which includes Tomcat. If you are running your own Tomcat install, you may need to hunt out the files yourself. This document is based on Linux. I’ve tried to point out what you need to change on Windows, but I don’t have a Windows box to test with.

My TeamCity home  is /opt/TeamCity

Enable JSP development mode in Tomcat.

This setting alows you to hot delpoy JSPs, and Tomcat will re-compile them for you without a restart.  Edit <TeamCityHome>/conf/web.xml and find the JspServlet section. Change the development mode to true as per the section below.

<servlet-name>jsp</servlet-name>
   <servlet-class>org.apache.jasper.servlet.JspServlet</servlet-class>
     <init-param>
       <param-name>development</param-name>
       <param-value>true</param-value>
     </init-param>
  ...

Enable Java code hot-swapping with a debugger

We have enabled JSP hot-compile in the previous, now we need to configure Tomcat so that Eclipse can load new Java code into the JVM from within the Eclipse debugger.

For Linux, edit <TeamCityHome>/bin/teamcity-server.sh and insert the commands needed to start Tomcat with the debugger enabled. I added the TEAMCITY_DEBUG_OPTS variable, and then added it to the CATALINA_OPTS line.

TEAMCITY_DEBUG_OPTS="-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n"

 CATALINA_OPTS="$CATALINA_OPTS $TEAMCITY_SERVER_OPTS $TEAMCITY_DEBUG_OPTS -server $TEAMCITY_SERVER_MEM_OPTS -Dlog4j.configuration=file:$BIN/../conf/teamcity-server-log4j.xml -Dteamcity_logs=../logs/ -Djava.awt.headless=true"

For Windows, edit <TeamCityHome>\conf\teamcity-server.bat and insert the debug commands. I added the TEAMCITY_DEBUG_OPTS variable, and then added it to the CATALINA_OPTS line.

:server_mem_opts_done
SET TEAMCITY_DEBUG_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket,address=8000,server=y,suspend=n
SET CATALINA_OPTS=%TEAMCITY_SERVER_OPTS% %TEAMCITY_DEBUG_OPTS% -server %TEAMCITY_SERVER_MEM_OPTS_ACTUAL% -Dlog4j.configuration=file:../conf/teamcity-server-log4j.xml -Dteamcity_logs=../logs/

Start Tomcat

Stop Tomcat if it’s running and then start it by running <TeamCityHome>/bin/teamcity-server.sh start (or <TeamCityHome>\bin\teamcity-server.bat start on Windows).

Have a look in <TeamCityHome>/logs/catalina.out  There should be a line similar to the one below indicating that Tomcat is running with the debug port open.

Listening for transport dt_socket at address: 8000

Configure Eclipse

In Eclipse, create a new Debug Configuration (In the Java perspective, it’s under the Run menu).

Find Remote Java Application, and click the new button.  In the Connect tab, set:

• Connection Type: Standard Socket (Attach)
• Connection Properties:
  • Host: localhost (assuming your TeamCity instance is on your local machine)
  • Port: 8000

In the Source tab, I added my Java source directory.

Connect to Tomcat in Eclipse

Run the new Debug Config, and change to the Debug perspective. A quote from the TeamCity dev page is relevant here.

if you do not change code affecting plugin initialization and change only body of the methods, you can attach to the server process with a debugger and hot-swap the code

So if you change your registers or constructors, you need to restart Tomcat.

Deploy your JSPs

When TeamCity starts, it copies the JSPs from your plugin into <TeamCityHome>/webapps/ROOT/plugins/<YourPluginName>/

Therefore, you can copy updated JSPs to here. This might be best acheived with a simple ANT script.

Announcing a beta release (version 0.5.5.5) of a plugin for TeamCity which enhances TeamCity to provide WebHook functionality. With the tcWebHooks plugin installed, you can tell TeamCity to trigger a webhook POST request as build events occur.

WebHooks are configured on a project basis, and when events occur in the build process, a POST request is submitted to the URL. You can configure as many URLs as you like (within reason) and which events will trigger the request.

There is support for proxies in this version, and webhooks are configured in the TeamCity UI. There are a few outstanding items to tidy up, but the core functionality is working.

The project is on SourceForge at tcplugins.sourceforge.net.

Last week was fun…

I setup Continuous Integration for my project using Team City. The project source is in Subversion and it’s a Maven project, so that was pretty easy to configure in Team City. Also had to install a Repository Manager Archiva to host maven dependencies. Team City is just awesome, can’t say enough about it. I did briefly look at other CI server products, but nothing as slick and team city.Team City’s “Remote Run” is THE feature any developer could ask for.

When all is done, I even prepared a little presentation with a brief overview of all the tools:

A disclaimer about the presentation: All (or most) of the images or text are either from product documentation or other articles I gathered.

Evolving Your Build Automation Solution
Implementing TeamCity for .Net Projects,Part1:Just Build It!(A Simple Build Configuration)
Implementing TeamCity for .Net Projects,Part2:Triggering Builds
Implementing TeamCity for .Net Projects,Part3 : Running Test,Nightly Builds and Creating Artifacts

TestComplete integration into TeamCity

We use TestComplete for GUI testing in our work. For faster tests execution we use several PC’s with TestComplete. A unique part of full task list runs on each PC.

But how can we split task for maximum workload of PC? How to combine results without manual work?

It also would be good to include GUI testing in to continuous integration process. As a continuous integration server we use TeamCity. TestComplete can be simply integrated into native AutomatedQA continuous integration server. But this server doesn’t fit our needs. It’s payware and doesn’t support pre-tested commit.

We need to create this:

TeamCity runs GUI tests on all TestComplete clients. NUnit runner will be used as a program which starts distributes tests. All test results will be combining in TestFixture ctor. All TestComplete PC’s has a small web service to handle TeamCity request on test.

Let’s start. On all TestComplete PC we run web service. TeamCity contains project that contains Nunit TestFixture for distributed test run. Web service runs application by client’s parameters. Message sequence on initialization and run test.

As a dispatcher algorithm we use “round robin”. We need simply thread manager for controlling active thread count and providing simple algorithm of synchronization.

[CODE language="CSharp"]
using System;
using System.Collections.Generic;
using System.Threading;

namespace ThreadLib {
///interface for thread result
public interface IThreadResult { }

public delegate T FuncDelegate() where T : IThreadResult;//wrapper for delegate

public class ThreadControler where T : IThreadResult {
private class ThreadParam {
public string Id;
public FuncDelegate Delegate;
}
///delegates for execution
private readonly Dictionary> Delegates = new Dictionary>();
///results
private readonly Dictionary Results = new Dictionary();
private int _MaxParalelThreadCount;
private static Semaphore Semaphore;

public ThreadControler(int maxParalelThreadCount) {
MaxParalelThreadCount = maxParalelThreadCount;
}

public T GetResult(string key) {
if (!Results.ContainsKey(key))
throw new ArgumentException(string.Format(“no result by this key {0}”, key));
return Results[key];
}

public void AddDelegate(string key, FuncDelegate @delegate) {
Delegates.Add(key, @delegate);
}
public int MaxParalelThreadCount {
get { return _MaxParalelThreadCount; }
set {
if (value < 1)
throw new ArgumentException(“value<1");
_MaxParalelThreadCount = value;
}
}
///wrapper for delegate
public void ThreadFunc(object param) {
var threadParam = (ThreadParam)param;
var result = threadParam.Delegate();
lock (Results) {
Results.Add(threadParam.Id, result);
}
Semaphore.Release();
}
///run all delegate in parallel mode
public void Run() {
if (Delegates.Count == 0)
throw new InvalidOperationException(“No Thread for Start”);
if (MaxParalelThreadCount < 1)
throw new InvalidOperationException(“MaxParalelThreadCount<1");

using(Semaphore = new Semaphore(MaxParalelThreadCount, MaxParalelThreadCount)){
var threads = new List();
foreach (var key in Delegates.Keys) {
Semaphore.WaitOne();
var localKey = key;
var @delegate = Delegates[localKey];
var param = new ThreadParam { Delegate = @delegate, Id = localKey };
var thread = new Thread(ThreadFunc);
threads.Add(thread);
thread.Start(param);
}
foreach (var thread in threads)
thread.Join();
}
}

}
}

[/CODE]

Web service for running and controlling application (TestComplete for example)

For Service creation I choose WCF. Here simple interface of service:

[CODE language="CSharp"]
[ServiceContract]
public interface ISpreadRunnerService {
[OperationContract]
TaskResult TryRunProgramm(string @executable, string @params, int timeout);
}

[/CODE]

For using this server need simple send “exe” name, params for “exe”, and timeout. Also we need to know busy server or not.

Service implementation:

[CODE language="CSharp"]
[ServiceBehavior(InstanceContextMode = InstanceContextMode.Single, ConcurrencyMode = ConcurrencyMode.Multiple)]
public class SpreadRunnerService : ISpreadRunnerService
{
private readonly object Locker = new object();
//strategy how to run app and how to get app results
protected IRunProgramStrategy Strategy;
public virtual TaskResult TryRunProgramm(string executable, string @params, int timeout)
{
//Lock service!!!
if (!Monitor.TryEnter(Locker))
{
return Strategy.NotRunResult;
}

var result= Strategy.Run(executable, @params, timeout);
Monitor.Exit(Locker);
return result;
}
///

[/CODE]

SimpleRunStrategy code part. Only run application and return application exit code.

[CODE language="CSharp"]
[DataContract]
public class TaskResult : ITaskResult {
[DataMember]
public bool Runned { get; set; }
[DataMember]
public bool Hang { get; set; }
[DataMember]
public int ProgramResult { get; set; }
[DataMember]
public string ExtraData;
}
public interface IRunProgramStrategy {
TaskResult Run(string executable, string @params, int timeout);
TaskResult HangResult { get; }
TaskResult NotRunResult { get; }
}
public class RunProgramStrategySimple : IRunProgramStrategy{
/*…*/
public virtual TaskResult Run(string executable, string @params, int timeout) {
TaskResult result=null;
try {
BeforeProcessRun();
Process p = new Process();
p.StartInfo.FileName = executable;
p.StartInfo.Arguments = @params;
p.Start();
p.WaitForExit(timeout);
if (!p.HasExited) {
p.Kill();
result= HangResult;
}
else
result= new TaskResult { Hang = false, ProgramResult = p.ExitCode, Runned = true };
}
catch (Exception e){
result= NotRunResult;
Console.WriteLine(e.Message + ” “+executable+
” “+ @params);
}
finally{
AfterProcessRun(result);
}
return result;
}
/*…*/

[/CODE]

Client is also very simple. Here it’s implementation:

[CODE language="CSharp"]
public class Task
{
public string Id { get; set; }
public string Executable{get;set;}
public string Params{get;set;}
public int Timeout { get; set; }
}
public class SpreadRunnerClient
{
//our thread controller
private ThreadControler ThreadController = new ThreadControler();
//list of service host. May be better use UDDI but…
internal readonly List Hosts = new List();
//task –that stored in external file
private List Tasks = new List();
public IEnumerable getHosts()
{
while(true)
foreach (string host in Hosts)
yield return host;
}

// create runner delegates for all task and run them in parallel mode
public void RunAllTasks()
{
ThreadController.MaxParalelThreadCount = Hosts.Count;
foreach (var task in Tasks)
{
var lockref = task;
FuncDelegate func = delegate()
{
while (true)
{
foreach (string host in getHosts())
try
{
var binding = new WSHttpBinding(“WSHttpBinding_ISpreadRunnerService”);
binding.ReceiveTimeout = TimeSpan.FromMilliseconds(lockref.Timeout*2000);
binding.OpenTimeout= TimeSpan.FromMilliseconds(20000);
binding.SendTimeout = TimeSpan.FromMilliseconds(lockref.Timeout * 2000);
using (var client = new SpreadRunnerServiceClient(binding, new EndpointAddress(host)))
{
client.Open();
//try to run application in server
TaskResult result = client.TryRunProgramm(lockref.Executable, lockref.Params, lockref.Timeout);
if (result.Runned)
return result;
}
}
catch { }
}
throw new ApplicationException();
};
ThreadController.AddDelegate(lockref.Id,func);
}
ThreadController.Run();
}

[/CODE]

And finally we need to make TestFixture that contain SpreadRunnerClient. In TestFixtureSetUp we must Load All Task from file and give them into SpreadRunnerClient. And call SpreadRunnerClient::RunAllTasks. For handling results we need to write some Test methods, for example:

[CODE language="CSharp"]
private static void AssertTests(TaskResult res) {
bool isnormalresult = res.ProgramResult == 0 || res.ProgramResult == 1;
Assert.IsTrue(isnormalresult, “result is a ” + res.ProgramResult + ” |” + res.ExtraData);
Assert.IsFalse((res.ExtraData.ToLowerInvariant().Contains(“exception”)), res.ExtraData);
}
// ReSharper disable InconsistentNaming
[Test]
public void XXXX001() { var res = client.GetResultsById(“XXXX001″); AssertTests(res); }

[/CODE]

And finally we can run this test in TeamCity:

]]> http://chukovskij.wordpress.com/2009/03/23/howto-continuous-integration-for-rails-applications-in-git-with-teamcity/ Mon, 23 Mar 2009 12:01:59 +0000 chukovskij http://chukovskij.wordpress.com/2009/03/23/howto-continuous-integration-for-rails-applications-in-git-with-teamcity/

I’ve just setup RSpec tests on TeamCity 4.0.2 buildserver for my rails project that is located under GIT version control!

To install git plugin see instructions. If you don’t want to build git plugin manually your can take my build (22 march, 2009). Also I zipped it with correct folder structure (download gitagentzip.png and rename to “gitAgent.zip” )

Also don’t forget to:

1. Setup Project Directory (Server): path in VCS settings. This is destination path to folder where Git plugin will clone git repository.

E.g. your VCS Git settings will be like this:

If you leave Project Directory(Server) empty you will see NullPointer Exception:

jetbrains.buildServer.serverSide.ExecutionException: Unable to collect changes jetbrains.buildServer.serverSide.ExecutionException: Unable to collect changes at jetbrains.buildServer.serverSide.impl.BuildChangesCollector.collectChanges(BuildChangesCollector.java:1) at jetbrains.buildServer.serverSide.impl.BuildStarter$1.run(BuildStarter.java:21) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907) at java.lang.Thread.run(Thread.java:637) Caused by: java.util.concurrent.ExecutionException: jetbrains.buildServer.vcs.VcsException: ‘/usr/bin/git clone -n ssh://git@unit-249/~/browser.git /Users/romeo/app/TeamCity/work/git’ command failed. stderr: fatal: destination directory ‘/Users/romeo/app/TeamCity/work/git’ already exists. at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:222) at java.util.concurrent.FutureTask.get(FutureTask.java:83) at jetbrains.buildServer.serverSide.impl.CancelableTaskHolder.waitForTaskToComplete(CancelableTaskHolder.java:9) at jetbrains.buildServer.serverSide.impl.dependency.TopBuildDependencyGraphImpl.doCollectChanges(TopBuildDependencyGraphImpl.java:3) at jetbrains.buildServer.serverSide.impl.dependency.TopBuildDependencyGraphImpl.access$000(TopBuildDependencyGraphImpl.java:49) at jetbrains.buildServer.serverSide.impl.dependency.TopBuildDependencyGraphImpl$3.run(TopBuildDependencyGraphImpl.java:2) at jetbrains.buildServer.serverSide.impl.dependency.TopBuildDependencyGraphImpl$3.run(TopBuildDependencyGraphImpl.java:1) at jetbrains.buildServer.serverSide.impl.dependency.TopBuildDependencyGraphImpl$4.run(TopBuildDependencyGraphImpl.java:1) at jetbrains.buildServer.serverSide.impl.auth.SecurityContextImpl.runAs(SecurityContextImpl.java:24) at jetbrains.buildServer.serverSide.impl.auth.SecurityContextImpl.runAsSystem(SecurityContextImpl.java:31) at jetbrains.buildServer.serverSide.impl.dependency.TopBuildDependencyGraphImpl.runAsSystem(TopBuildDependencyGraphImpl.java:60) at jetbrains.buildServer.serverSide.impl.dependency.TopBuildDependencyGraphImpl.collectChanges(TopBuildDependencyGraphImpl.java:54) at jetbrains.buildServer.serverSide.impl.dependency.TopBuildDependencyGraphImpl.collectChanges(TopBuildDependencyGraphImpl.java:75) at jetbrains.buildServer.serverSide.impl.BuildChangesCollector.collectChanges(BuildChangesCollector.java:0) … 7 more Caused by: jetbrains.buildServer.vcs.VcsException: ‘/usr/bin/git clone -n ssh://git@unit-249/~/browser.git /Users/romeo/app/TeamCity/work/git’ command failed. stderr: fatal: destination directory ‘/Users/romeo/app/TeamCity/work/git’ already exists. at org.hivedb.teamcity.plugin.commands.CommandUtil.commandFailed(CommandUtil.java:32) at org.hivedb.teamcity.plugin.commands.CommandUtil.checkCommandFailed(CommandUtil.java:15) at org.hivedb.teamcity.plugin.commands.CommandUtil.runCommand(CommandUtil.java:39) at org.hivedb.teamcity.plugin.commands.GitCommand.exec(GitCommand.java:37) at org.hivedb.teamcity.plugin.commands.CloneCommand.run(CloneCommand.java:31) at org.hivedb.teamcity.plugin.GitVcs.getCurrentVersion(GitVcs.java:35) at jetbrains.buildServer.buildTriggers.vcs.VcsChangesLoader.getCurrentVersion(VcsChangesLoader.java:43) at jetbrains.buildServer.vcs.impl.VcsManagerImpl.getVersionsForAllRoots(VcsManagerImpl.java:415) at jetbrains.buildServer.vcs.impl.VcsManagerImpl.loadChanges(VcsManagerImpl.java:513) at jetbrains.buildServer.serverSide.impl.auth.SecuredVcsManager.loadChanges(SecuredVcsManager.java:72) at jetbrains.buildServer.vcs.impl.VcsChangesCollectorImpl$3.call(VcsChangesCollectorImpl.java:2) at jetbrains.buildServer.vcs.impl.VcsChangesCollectorImpl$3.call(VcsChangesCollectorImpl.java:1) … 5 more

2. Set VCS checkout mode to “Automatically on agent (if supported by VCS)”

3. git should be in system PATH

And my Rake build runner settings are:

Enjoy!