Yes, I wrote my own CI server. I even did it in Power Shell, because that looks cool. You can find the source here. It is currently running in production and is responsible for pushing NH Prof builds out.

Now, what was I thinking when I built my own CI server? Put simply, I had the following goals:

• Test WPF apps – CC.Net doesn’t allow it, since it is running as a service and that affects the way WPF tests behave. Texo shell out a different process, so it doesn’t have this limitation. Most other CI servers do the same.
• Don’t expose passwords – the thing that really killed me with CC.Net was looking at the build log and seeing my password right there in plain text (happens if there is connectivity error to the repository). Yes, I am also surprised this is a feature.
• Handle Git pushes – Git allows you to push several changes to the repository in a single shot. When I tried to use CC.Net to build NH Prof from git, it only showed the last commit. Texo understand the notion of a push (it takes it from the git hub API) and can pass that information to the build script.
• Reactive – Texo doesn’t check the repository, in fact, most of the time it is completely passive (and is likely to be shut down). Whenever a push is made to the repository, github will call the Texo’s url, providing the information about the current push. Texo will take that information and create the builder process, which will update / clone the new repository, and then execute the build command.
• Small configuration footprint – there are only two types of configuration, the SMTP settings and the project information. Here is the full configuration file:
  

<settings>
  <email>
    <smtpServer>smtp.gmail.com</smtpServer>
    <username>*****@gmail.com</username>
    <password>****</password>
    <useSSL>true</useSSL>
    <port>587</port>
    <from>*****@gmail.com</from>
  </email>
  <project
    url="https://github.com/ayende/Texo"
    name="Texo"
    git="C:\Work\Texo"
    ref="refs/heads/master"
    cmd="powershell .\psake.ps1 default.ps1 upload"
    build="3"
    workingDir="C:\Builds\Texo"
    email="ayende@ayende.com" />
</settings>

What it doesn’t do:

• UI, reports, tracking, whatever. Texo has one purpose in life, listen to changes and build the software, nothing else. The UI is a very simple email notification process, nothing more.
• Hung build recovery.
• Anything but git + github.

Texo is compromised of two parts, a web endpoint, written in C#, that plugs into IIS. I assume that the IIS website user is going to be the same one that the tests will run under (makes things much simpler). Once a notification arrives, the endpoint will invoke the Builder Power Shell script to perform the actual CI process.

At some point I really have to make up a list of all the projects that I was involved at, I know how I am going to title it: “NIH R US”.

Oh, and can you figure out the naming?