Saturday, April 29, 2006

Time to Synchronize...

I came across a weird situation a couple of months ago when I was setting up CruiseControl with Subversion.
There is a Subversion server on which our source code resided and I was setting up Cruise on another machine which was supposed to be our CI build machine.
Steps I followed:
  • Download and install CruiseControl
  • Do an initial checkout from the repository into the Cruise projects directory
  • Change the sample config.xml to set the build interval, repository location, publishing results etc etc.
  • To verify, force a build. (or checkin to the repository and see that it kicks off a build)
I did all this, and it worked perfectly fine and the build was successful.

But I found that later whenever some code gets checked in, cruise somehow was not picking up any modifications at all. After struggling a lot with the configurations and searching on the web I shot a mail to one of the people behind CC and quite soon, I had the answer.

There was a simple mistake that was causing Cruise to behave randomly. The problem was that the system time on the Repository server and the time on the cruise control box was not synchronized. There was some 5-6 hour difference between the two. CruiseControl checks for modifications that have happened after a given time. So if the time is not synchronized, obviously it wouldn't find modifications!

This is very important whenever CruiseControl and the Source repository are on different machines:
Make sure that the time/date on the cruise box is synchronized with the time/date on the repository box.
Btw, This may be helpful.

3 comments:

Pal said...

well, I think the SVN module of Cruise should rather ask the repository for modifications against it's current copy of the source than askin it for modifications since a given time..
coz at times, it's way too complicated to sync up the time b/w machines when they're in different TZs..
what do u think?

Karthik said...

Ya You are right... even I thought so. But consider a situation where Cruise is looking for modifications in a subset of the repository tree. If it uses the revision number for detecting modifications, I think it would detect modifications even if it is out of the subtree.
Doing a diff of the contents is obviously a bad idea.
I ran Cruisecontrol in debug mode and saw what svn command it executes to detect modifications. This is what it does:
svn log --non-interactive --xml -v -r {2006-04-07T05:36:07Z}:{2006-05-02T11:02:44Z}

Eventhough I do think this is not the best way, I have not yet found an alternative.

Siddhi said...

Wow, I'm facing this exact same problem, and I was scratching my head for quite a while as to why on earth is was not finding modifications. I've configured many CC setups, so I was pretty confused with this one, until I saw this post and realised that every other time I've had the CC server and the repository in the same time zone, and this is the first time they have been in different time zones.

This explains everything. Thanks. Maybe an attribute to specify the time difference would be good, something like

<svn localWorkingCopy="whatever" timezonedifference="-5.5"/%gt;

and it could add or subtract the value from the current time when making the query