Texo – My Power Shell Continuous Integration Server
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="firstname.lastname@example.org" /> </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?
Teamcity works great with github and wpf
what do you use for driving wpf tests?
Texo after the construction industry federation as you're doing some building here and there?
Care to throw out some PS resources you find useful? I'd recommend the PS In Action book myself....
No, that isn't t :-)
Never heard about this construction federation.
And I basically just started reading blogs
I also vote for TeamCity.
Ayende - do you sign T-shirts?
Real rock-star developer
@Ayende re the guess on the etymology... I Didnt really think it was going to be the first hit on Google!
Texo = The Egregrious Xml Omitter
NIH, after the NIH Syndrome...
And I think you meant that Texo is comprised , not compromised...
I wonder if you can get around the service problem by running CC.Net as a console application. That's how we got WatiN-based tests working on one project.
Of course, you lose the benefits of Windows services in the process.
Latin always impresses me.
Love these kind of light tools. We built something similar a few months back using Ruby instead of PowerShell.
Our solution was aimed for automatic deployment to staging or live. We have it so we can do "git push [deploy:staging]", and the GitHub hook triggers a URL, which then causes "git clone", MSBuild, tweaking IIS config and also the app config. All good honest time saving fun.
You're is gonna be more stable, so might grab it and have a play :)
maybe borrowing from the same origin as TeX, the superb typesetting system?
compromised -> comprised ?