Jim Hague wrote:
On Monday 27 March 2006 23:27, Eric Minick wrote:
Interesting. The problem we had seen earlier is that the SVN adapter had
been deciding it was time to build too frequently. I believe that was
addressed in the most recent build. The approach taken, roughly, is to
request a list of changes since the date of the most recent build. The
svn client will return too many results due to a subtelty in how it
handles revisions. The driver will then filter out any results that
appear to have been checked in before the previous build. If there are
any revisions remaining, the build will execute.
The 'Right Way' to determine whether a build is required with Subversion would
simply to be to look at the change number at the base of the repository - if
it is bigger than the change number at the previous build, off we go.
Anthill OS (I've not seen/used Pro) keeps this decision in generic code, not
on the repository driver. It stores the date/time it started the last build,
and asks the repository adapter for the date/time of the last change.
Unfortunately in the first version of the Subversion adapter I missed a
subtlety of Subversion behaviour. If you ask Subversion for changes since a
particular date, what it gives you back is a list of the changes comprising
the active change at that date and all subsequent changes. This would mean
that typically Anthill would build a new change twice, the second being
kicked off because the change that caused it was the active change at the
time of the first build. This is fixed in the latest Anthill OS by simply
filtering out any changes with a date before the last build time.
My first guess would be that the build server and svn server have clocks
which are wildly out of sync. Is that possible?
I'm running Anthill OS on Linux, so there may be Windows issues I am unaware
of. If it is never running a build, then I think this must be a problem with
the last build date.
What is the content of the project file? This is under 'projects', and named
<project>.anthill. Here's the relevant bit of one of mine:
anthill.lastBuildFailDate = 03/15/2006 23:56:06
anthill.lastBuildSucceeded = true
anthill.lastGoodBuildDate = 03/27/2006 20:54:54
I'm wondering if either this date is being interpreted as way in the future,
or else if something about how dates are handled in the Subversion adapter is
causing problems in the Windows world. If you set logging to debug, then each
check will produce some chatter from the Subversion adapter which should help
pin it down.
Hi Jim, thanks for the help. I've checked my project file and the
pertinent information is as follows:
anthill.lastGoodBuildDate = 04/03/2006 13:22:59
anthill.lastBuildSucceeded = true
And I know for a fact that I have made a revision since this date.
When I turn debug on the relevant chatter is as follows:
<timestamp> [Thread - AnthillBuildDaemon] INFO
com.urbancode.anthill.BuildManager - step 2) is project up to date?
<timestamp> [Thread - AnthillBuildDaemon] DEBUG
com.urbancode.anthill.BuildManager - last good build date: Mon Apr 03
13:22:59 EDT 2006
<timestamp> [Thread - AnthillBUildDaemon] DEBUG
com.urbancode.anthill.adapter.SubversionRepositoryAdapter - Get
revisions since command: svn log --non-interactive -v --username
"anthill" --password "anthill" -r "{2006-04-03 13:22:59 -0400}:HEAD"
svn://localhost/repos/TestApp
<timestamp> [Thread - AnthillBuildDaemon] DEBUG
com.urbancode.anthill.adapter.SubversionRepositoryAdapter - returning
revisionList
<timestamp> [Thread -AnthillBuildDaemon] INFO
com.urbancode.anthill.BuildManager - Build NOT required
<timestamp> [Thread -AnthillBuildDaemon] INFO
com.urbancode.anthill.BuildManager - Build NOT required.
The <timestamp>s are all between 15:48:04:140 and 15:48:04:531.
I was looking through the code and noticed that in
SubversionRepositoryAdapter.parseLogCommandResult() there are alot of
log.debug() messages not showing that would show up if this for loop
were to be executed:
for ( String line = br.readLine(); line != null; line = br.readLine() ){
... }
where br is a BufferedReader supposedly containing the results from the
svn log command. So my guess is that this command isn't returning
anything or hasn't returned anything when it's results are parsed. If
I manually execute the svn log command I do get results so I'm pretty
sure it's not the command itself. I'm wondering if maybe the command
hasn't yet returned anything when this for loop is executed.
The block of code where parseLogCommandResult() is called looks like
this:
p = Runtime.getRuntime().exec(toArray(commandString));
// pump the error stream.
errorPumper = new StreamPumper(p.getErrorStream(),
"getRevisions",
System.err, true);
errorPumper.start();
// get and parse the input stream
InputStream input = p.getInputStream();
parseLogCommandResult(input, revisionList, date);
exitcode = p.waitFor();
I'm going to try and see if calling exitcode = p.waitFor(); before
calling parseLogCommandResult(input, revisionList, date); will fix
this. But I have never built Anthill before so that might be opening a
whole new can of beans. Anyway, any help would be appreciated, thanks,
Philip.
AND it's getting even more confusing - at least to me. When the build seems to be sleeping at [echo] Updating codes and MLS on db EAHVWORK_INIT.LPDOMAIN! [echo] Using JDBC driver at \\lpsrv06\BuildSystem/eAHV_B/Nightly/../../JaXLionCommonRuntimeLibs/Nightly/ Latest/oracle_jdbc14_9205.jar... [echo] Using the following parameters: oracle.jdbc.driver.OracleDriver, jdbc:oracle:thin:@debie.akbnet.be:1521:eahvb, myuser, mypassword I stopped the Tomcat Windows service (Anthill is running inside Tomcat). All of a sudden once Tomcat is stopped I'm seeing more output in my build log!!! [sql] Executing commands [sql] 21 of 21 SQL statements executed successfully This is what I was expecting in the first place! With ProcessExplorer I checked the active Windows processes and threads and I discovered that the Java process that was dispachted for the build was still running. Hence, the build that was interrupted for whatever reason was running after Tomcat was restarted.
> If this is the case then I thought the problem was with the
> fact that my author, I have "(no author)", contains a space.
Ahhhhh! Or, indeed, aaarrgggghhhhh! Yes, that would indeed cause the problem.
I didn't realise this was possible. Having checked the Subversions FAQ, do I
assume someone is accessing the repository via anonymous write acces to
Apache?
> So the space would break the (\\S+) part of the expression but this
> isn't followed by a ' | '. So I tried replacing the expression with:
>
> "^r(\\d+) \\| ([^\\|]+)\\| ([^\\(]+)"
>
> Running with this expression worked, awesome, thanks for your help.
Good news, and thank you for your persistence and getting to the bottom of
this.
I'll redo the regular expression along the lines you outlined and send a patch
to Urbancode.
(I know that in one sense I should be using the 'svn log' XML output here. But
frankly, I don't want to haul in an XML parser when parsing the regular
output via REs is so quick and easy).
RSS Feed