Warning: strpos(): needle is not a string or an integer in /customers/a/f/c/fjorden.se/httpd.www/joel/index.php on line 49 Warning: count(): Parameter must be an array or an object that implements Countable in /customers/a/f/c/fjorden.se/httpd.www/joel/scripts/sb_display.php on line 480 Blog by Joel Fjordén a.k.a. Will o Wisp - Temporarily Disable Push in Mercurial (Hg)
Temporarily Disable Push in Mercurial (Hg) 
Thursday, July 7, 2011, 07:26 AM - General
We use Mercurial and TeamCity as CI server and have been experiencing some problems lately when developers are pushing Hg change-sets to the server when a build is in progress. The problem is that TeamCity first pulls and updates before starting the build and then during the build some files are generated and/or updated, like help files and version files (but also the .hgtags file). Then as the final step in the build process when it’s time for TeamCity to commit and push the changes there will be a problem if a new push has been made since the start of the build process, i.e. we will get an error message like "push creates new remote heads".

One solution to this is of course to pull, update, merge (if needed) and commit, or the Hg Fetch extension, but what we really wanted was to somehow prevent developers to push change sets into the remote server repository during the build process of that specific project in TeamCity.

After quite a lot of research on Google, I still couldn’t find any existing solution to this, so I started thinking about how we could manage this ourselves. The solution I came up with was to develop a very simple, but yet quite smart, REST service hosted on the same machine as the Hg repositories. The service exposes endpoints for EnablePush/DisablePush together with the name of the target repository. What the service implementation does is then to temporarily change the hgrc file in the repository to disable push, but not for everyone, since the automated build account used by TeamCity for Mercurial still needs Push access (allow_push = Mercurial). In order to enable Push again when the build is completed we then allow everyone with an account in the AD to Push again (allow_push = *).

In order to use the REST service from TeamCity I discovered a very useful plugin called tcWebHooks that allows HTTP POST on TeamCity events like build started and build completed. Here is a configuration example of tcWebHooks for enabling/disabling Hg Push for a specific project and repository using the custom made RIA service.

If you’re interested in the service install package or source code, let me know and I’ll send it to you!
1 comment ( 124 views )   |  related link

Code Style Enforcer 3.0.51 Supporting DXCore 10.2.5 
Monday, March 7, 2011, 09:12 PM - Code Style Enforcer
Code Style Enforcer 3.0.51 rebuilt against new version of DXCore 10.2.5.

Download Code Style Enforcer 3.0.51
2 comments ( 175 views )   |  related link

Code Style Enforcer 3.0.43 Supporting DXCore 10.2.3 
Sunday, December 12, 2010, 07:45 PM - Code Style Enforcer
This is simply a rebuild of Code Style Enforcer version 3.0.32 in order to support the new version of DXCore 10.2.3.

Download Code Style Enforcer 3.0.43
3 comments ( 175 views )   |  related link

Code Style Enforcer is Currently Incompatible with DXCore 2010 vol 2.3 
Thursday, December 9, 2010, 07:04 AM - Code Style Enforcer
Today I upgraded from DXCore 2010 vol 1.8 to version 2010 vol 2.3 and then I got an error message as soon as I loaded a solution.

There seems to be some incompatibility issue with this new version of DXCore, but a new version of Code Style Enforcer targeting DXCore 2010 vol 2.3 will be released within the next couple of days!

1 comment ( 114 views )   |  related link

Code Style Enforcer v.Next 
Wednesday, November 17, 2010, 05:51 PM - Code Style Enforcer
I thought I was going to enlighten you all of what's currently going on with Code Style Enforcer.

Right now I'm looking into a more flexible code rule system, where it should be possible to fine tune rules based on a combination of code type (field, method, etc.), visibility (public, private, etc.) and keyword (static, readonly, const, virtual, etc.).

My thought is that it should also be possible to choose the current standard, and easier, configuration of name rules, but that it also should be possible to specify custom regular expressions, probably resulting in the loss of automatic name corrections or suggestions.

The other relatively large implementation feature is to enable Code Style Enforcer to enforce the rules during MSBuild, either inside Visual Studio or through the command-line, e.g. automatic build server. Inside Visual Studio the violations will be added to the Error List tool window as either warnings or errors depending on configuration.

I think and hope these features are something you all have use for, but please let me know if anything else comes to your mind.
2 comments ( 88 views )   |  related link

Back Next