A few months ago at work we moved from Subversion to Git, which has caused us to make many process changes within our development team. By forcing everyone to work in a new Git branch for every task has added overhead to the build management process. Several of us have slowly been getting tired of manually creating new TeamCity build configurations just to run a single build that we later have to manually remove after our release managers have merged our changes.
To remove some of this burden we needed TeamCity to automatically create configurations for all our private development branches, so in lieu of the excellent JetBrains team building this feature (TW-16052), I very quickly wrote an app that does just that for us.
I was asked by a few in the TeamCity issue above to provide the code we are using, so I have uploaded a slightly modified version of the code to GitHub. The app is written in C# and uses the libgit2sharp library, but could easily be ported to another language or the command line tools respectively.
So that a few things make sense when you read it, our private development branch convention is "private/username/anything", so with a single TeamCity project for these branches it will name them "username-anything". You'll see that when it creates the build configuration it creates it from our branch template and sets the BRANCH_NAME configuration variable, which we use as the Ref name in a VCS root (i.e. %BRANCH_NAME%).
https://gist.github.com/1397643
I have been extremely quiet on my blog for the last 12 months or so, however I'm alive and well, I just haven't had much to say.
After many requests for Visual Studio 2010 support for Castle Visual Studio Integration, I did the pretty painless work back in November 2010, but just didn't get around to releasing it.
You can now download the source code from GitHub and get the binaries via the Visual Studio Extension Manager. See the
CVSI page for full details.
Today, I am announcing the first public preview of a RubyGems-inspired package manager for .NET, Bricks.
Bricks is very basic at this point, however over the coming months I intend to continue improving it and its central repository to benefit both myself and the wider community. At the moment the only thing I can guarantee is that things will break because supporting backwards compatibility is not important.
I welcome you to download and take a look at Bricks. If you have ideas or want to discuss things I would prefer the discussion to occur on the mailing list, rather than the comments here.
I have just committed some logging (r6370) into the DynamicProxy codebase which will be in the soon to be released v2.2.
Krzysztof Koźmic suggested a few weeks back that we should add some logging mainly around type caching and anything else that may help users diagnose common problems.
In the screenshot you can see examples of the logging that you can enable. Note that the blue info messages were logged by the demo console application not by DynamicProxy.
The logging is implemented using the Castle logging infrastructure so Windsor can provide an ILogger directly to a ProxyGenerator. If a ProxyGenerator class is not instantiated by a container the default logger that DynamicProxy uses is a trace logger set to display messages at the warning level. By default this means that any messages at warning or higher logged by DynamicProxy will be visible in the Visual Studio output window.
If you have feedback on the DynamicProxy logging, or ideas for more logging then let us know on the mailing lists.
Castle NVelocity 1.1.0 and the Castle TemplateEngine component 1.1.0 have just been released. Many thanks to the TemplateEngine project lead John Simons.
Visit the
Castle Project web site for download details.