Observation + advance warning

Observation + advance warning

[Kris Van Hees]

Last night's automated build-and-test run was the first of its kind in
that the build actually failed due to CVS' limitations, i.e. being
unable to guarantee atomic commits.  As such, it looks like the
automated build was updating its tree at about the same time as Chris
Moller commiting the test for kernel buf 232837.  The result was that
the incremental update tree contained the Makefile.am from the commit
but not the kernel232837 directory with the actual test case.
Obviously, this broke the build.

There isn't really any good solution to this problem in terms of CVS,
since we obviously wouldn't want to do a full lock on the tree for the
purpose of doing build-and-test run checkouts and update.  As such, be
forewarned that we're going to have days where the build will be
reported as failing without there really being a mistake on anyone's
part.

I'll kick off a manual run this morning, and post those results in lieu
of last night's results.

	Cheers,
	Kris

Re: Observation + advance warning

[Andrew Cagney]

Kris,

I'm guessing that the, at present, the snapshot date/time is determined 
by when ever the corresponding CVS commands are run.  Unfortunatly that 
means that it is impossible for anyone to reproduce a test run :-(  Can 
the scripts be modified to specify << -D YYYY-MM-DD-gmt >>, i.e., 
midnight GMT, as the checkout/update date?  The alternative would be to 
use tags, I don't think that is realistic.  Of course the tests can be 
run several hours after midnight GMT -  "in the local wee hours" so to 
speak.

The chance of someone actually committing across GMT is very very low, 
having implemented a number of snapshot/build systems, I've never seen 
it as a problem.

Andrew

(version.in updates slightly before midnight gmt so that it is correct)

Kris Van Hees wrote:
> Last night's automated build-and-test run was the first of its kind in
> that the build actually failed due to CVS' limitations, i.e. being
> unable to guarantee atomic commits.  As such, it looks like the
> automated build was updating its tree at about the same time as Chris
> Moller commiting the test for kernel buf 232837.  The result was that
> the incremental update tree contained the Makefile.am from the commit
> but not the kernel232837 directory with the actual test case.
> Obviously, this broke the build.
>
> There isn't really any good solution to this problem in terms of CVS,
> since we obviously wouldn't want to do a full lock on the tree for the
> purpose of doing build-and-test run checkouts and update.  As such, be
> forewarned that we're going to have days where the build will be
> reported as failing without there really being a mistake on anyone's
> part.
>
> I'll kick off a manual run this morning, and post those results in lieu
> of last night's results.
>
> 	Cheers,
> 	Kris
>