Re: [Xen-devel] [xen-unstable test] 17327: trouble: broken/fail/pass

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 25.03.13 at 13:44, Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx> wrote:
> Jan Beulich writes ("Re: [Xen-devel] [xen-unstable test] 17327: trouble: 
> broken/fail/pass"):
>> >>> On 19.03.13 at 03:36, xen.org <ian.jackson@xxxxxxxxxxxxx> wrote:
>> > flight 17327 xen-unstable real [real]
>> > http://www.chiark.greenend.org.uk/~xensrcts/logs/17327/ 
> ...
>> I don't see how I could prove that. Is there any other way to
>> associate the log of a particular run with the top level commit of
>> the originating source tree?
> 
> If you look at one of the build-* columns (click on the column
> heading) you see a table of "Test control variables".  Here, for
> example:
> 
> http://www.chiark.greenend.org.uk/~xensrcts/logs/17327/build-amd64/info.html 
> 
> There you can see the revisions of the various trees used.  It also
> does a check afterwards (using "git-rev-parse HEAD", for example) and
> records the result as built_revision_...

Not exactly, I'm afraid - what a particular test job uses apparently
isn't tied to just a single build, or else I don't understand how an
older build's output could turn out to be visible in the serial log. And
it's those older builds that leave traces in the serial log that I've
been looking at here (in particular to spot whether the "No irq
handler for vector ..." and the platform timer wrapped messages
still appear after the two HPET related changes).

Furthermore, those test results, iirc, get purged from the server
after a while, so if I store local copies of some of the logs and fail
to note down the underlying commit ID(s), then I won't be able
to associate the logs back.

With hg, the information was readily available at the top of the
hypervisor log, and I think we really ought to bring this back for
git.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel