-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Seen using AccuRev plugin 0.6.12-SNAPSHOT (private-10/27/2010 12:41-root), which was obtained from http://ci.hudson-labs.org/job/plugins_accurev/3/org.jvnet.hudson.plugins$accurev/
Hudson has a setting (in Manage Hudson -> Configure System) called "SCM checkout retry count".
When set to a (non-zero) number, this causes Hudson to retry a build if a Hudson's initial attempt to talk to an unreliable source-code repository fails, thus ensuring that builds don't start going red just because the source code repository suffered an outage.
This is a very important feature when using AccuRev, as the AccuRev client sometimes returns truncated or corrupted data (often enough to cause problems), causing the series of AccuRev operations that the Hudson plugin does to report a failure: Retrying the build usually results in the AccuRev client behaving itself and the build proceeds as expected.
Unfortunately, if one has ticked the new "Create and build from snapshot" facility and the previous build attempt fell over after the "create snapshot" phase, the subsequent retry will then fail to create a snapshot (as one already exists).
I would suggest that, if the "create snapshot" operation fails because the snapshot already exists, then the build should populate from that existing snapshot and continue as normal.
That way, the snapshot represents the code that we first attempted to build, and subsequent builds can build later versions of the code.
One thought that does occur to me: This may require that the "when we last built the code" SCM polling information be set to the last successful snapshot datestamp, rather than the time that the build first got past the "get the code out of the SCM" stage.