CruiseControl.NET and PowerShell–Take 2

I got some good feedback on my last post about building a PowerShell provider for CruiseControl.NET. Basically the question was whether using PS drives was the best approach to use – especially for managing multiple servers. So I have completely refactored the cmdlets to not need the PS drive – and the good news is this has made the coding even easier

Here are the cmdlets that are current exposed:

Most of these were in the previous version – but there is one major change – New-CCConnection has replaced Get-CCServer. I’ll come back to why for this later on.

So with the changes the commands now look like this:

To work with projects we now directly use Get-CCProject rather than using Get-ChildItem. This has been simplified to take in either the server name or connection and directly return the projects. This can also be filtered by putting in a name parameter.

In the screenshot above I’m directly working against the name of the server (in this case localhost.) To allow this I’ve made some changes to the name resolution. If connecting to localhost or 127.0.0.1 it will use .NET Remoting (TCP connections) – all other names will default to HTTP. It is still possible to connect via .NET Remoting – just have to put in the full URI for the server (including the protocol.)

I’ve also expanded the connections out so it is possible to use a backwards compatible connection (for connecting to pre-1.5 version servers) and allow encrypted connections. These can be turned on by adding the relevant flag to the command (note – they are mutually exclusive – if both are used an error will be thrown!)

Now to simplify connecting to a server I have added a cmdlet called New-CCConnection. This will take in the parameters for a connection and return a connection instance (if the connection is valid.) This connection can then be used in any of the commands. Now, while this may seam to add overhead (beyond reducing the number of keystrokes per command) the beauty of the command comes when we want to use security. For example if we have a secured server:

In this screenshot I started two connections – the first time it was an unsecured connection, the second it was secured. Both connections can view the projects (this is the way security has been configured) but only the second connection can force a build.

And for a final fun example, here is a screen shot showing how it is possible to work with multiple servers at once:

I don’t actually have two servers running – hence all the projects are duplicated – but it shows how we can set up two different connections and pipe them into the Get-CCProject cmdlet to retrieve all the projects. Note there are no queues for the connection that uses backwards compatibility as this feature was added in v1.5.

So hopefully this is more useful now. For my next post I’ll try and add some new functionality to make the cmdlets more useful

CruiseControl.NET and PowerShell

It’s been a while – I’m still busy with work, study and a family – not as much time to write as I would like

I’m currently playing around with PowerShell in my job at the moment. Basically we never have enough time, so I’m trying to figure out how to automate various tasks via PowerShell. And I’ll admit, so far I like it! It is easy to use, has a lot of power and flexibility and there are limitless possibilities for what can be done. But this post isn’t about PowerShell in general – instead I’ve been playing around with building a PowerShell provider for CruiseControl.NET.

“What? But why?” you might say. A while back I built a command-line tool that allows people to interact with a CruiseControl.NET server. But it is very limited and is fairly complex for what it actually does (in terms of the code for it.) As I was playing around with PowerShell I started thinking a lot of the syntax in PowerShell would allow me to build a much better command-line tool, especially when I started seeing the extensibility options for PowerShell.

So I have started putting together a PowerShell provider for CruiseControl.NET. This allows an administrator to connect to a CruiseControl.NET server and administer it. As I’m still playing around with things the code is production quality yet, so use it at your own peril! There is no installer – you will need to grab the code off SourceForge and build it, then copy the contains of the PowerShell\Bin\Debug folder into your modules directory (see help about_modules in PowerShell.)

However if you are interested in seeing what can be done, take a look at the following screen shots:

Here I am:

• Importing the module
• Seeing the new drive that has been mapped
• Getting the child items in the various folders
• Starting all the projects
• And forcing a build for all the projects

I like how I can work with multiple projects at the same time – in my previous tool we would have needed to run the tool once for each project!

I have implemented the cmdlets in the provider to use the pipeline, so we can use a lot of the functionality within PowerShell. For example if we only wanted to get the projects for a certain queue:

This is something that wasn’t even thought of in the command-line tool! And here it is, without any extra work on my behalf

At the moment I have only implemented four cmdlets:

• Get-Log
• Start-Project
• Stop-Project
• Start-Build

Plus the provider infrastructure (i.e. you can use built-in cmdlets like Get-Item, Get-ChildItem, Set-Location, New-PSDrive, etc.) Currently I have mapped the local server to local:. It is possible to connect to other server using New-PSDrive as long as you know the address for it (this is the same address that CCTray uses.) I have implemented the provider as a hierarchy. The top level is the server itself, with two sub-folders: Queues and Projects.

My next step is to add builds in, but I think this is going to need some changes on the server side to work.

Hopefully this will be helpful to someone