Trosnoth: Mercurial server

Myself and the other Trosnoth developers have been looking at moving from subversion to mercurial for our source code control. I’ll blog about some of my adventures doing the conversion later, because today I want to talk about the mercurial server I’m setting up.

I’m setting up a computer to host our central repository of Trosnoth code. For now it’s just running a simple mercurial server. What I want it to do eventually is:

  • run all our unit tests on the default branch whenever a developer pushes code (unless the tip of default doesn’t change—this allows developers to push broken code in branches but not in default);
  • if any unit tests fail, decline to accept the push;
  • generate code coverage reports for the test results;
  • if any source file has had its code coverage percentage decrease from the previous revision, decline to accept the push (with some minimum percentage for new files which are pushed); and
  • if a developer tries to push while another developer’s changes are being tested, queue the new changes and test them once the last test run is finished.

I’ve done some preliminary research and I think that this should be possible. Here’s how I plan to do it:

  • write a pretxnchangegroup hook in the mercurial repository, which:
    • uses hg bundle –base to create a bundle of the changes,
    • uses the bundle-testing script to queue testing of the bundle,
    • prints a message to the user, and
    • refuses to accept the changegroup transaction;
  • write a bundle-testing script, which goes through every queued bundle and:
    • clones the repository,
    • applied the bundle to the new test repository,
    • does an automated merge if needed (e.g. if two bundles were queued and one has been accepted, therefore the second one will create a new head),
    • build a source distribution from the code,
    • install the source distribution in a test environment,
    • run the unit tests,
    • if any of the above steps fails, send an email to the user who did the push, indicating the reason of the failure,
    • otherwise the bundle is accepted, so apply it to the real repository.

Overall, this should improve the code quality of the program.

This entry was posted in midlength and tagged , , , . Bookmark the permalink.

Comments are closed.