Paul,

Before I start picking holes and asking questios: Thanks for doing this it 
looks like you are starting on the right track!

On Wednesday 12 Dec 2012 13:17:05 Paul Sokolovsky wrote:
> Hello,
> 
> As a heads-up for CBuild/LAVA integration project,
> http://ec2-54-243-13-36.compute-1.amazonaws.com/helpers/scheduler is now
> available, which has initial(?) web frontend integration with LAVA.
> That page (currently) shows job "gcc-linaro-4.6-2012.09.job", submitted
> against queue "lava-panda-mock", with a link to latest build in LAVA
> (extra feature, I couldn't find a way in CBuild frontend to get to
> native build results).

So as soon as a board starts executing a job it should no longer appear in the 
'Pending' list - just the Jobs list see:
    http://cbuild.validation.linaro.org/helpers/scheduler
This is the moment the 'Taken' column gets filled in.

You know a job has finished because it appears in recent:
 http://cbuild.validation.linaro.org/helpers/recent
These have a direct link to the build logs.

You can also get to the build logs via:
 http://cbuild.validation.linaro.org/helpers/buildlog

> If you want to try it yourself, it's accessible to same TCWG people as
> http://cbuild.validation.linaro.org/ , plus me, Stevan, and Danilo. So,
> if you're not in list, please drop us a line. "Spawn" and "Bump up"
> actions support integration with LAVA currently. We're in the process
> of identifying what other features of web frontend would require LAVA
> integration, hints from TCWG are appreciated.

Spawn and Bump up seem a good start.

'Release' would be useful as well - which actually means: 'Respawn' (i.e. do 
it again)

Another one which would be useful (and which we currently do manually with 
"killall make" on toolchain64.lab) is: Kill all current jobs.  This is useful 
in release week when we want to clear the way for the release builds.

> Now a bit about architecture. We're targetting to support both native
> CBuild and LAVA schedulers. This is per-queue, i.e. one queue can use
> native scheduler and another LAVA. LAVA is detected by the presence of
> LAVA job definition template file in a scheduler queue dir:
> http://bazaar.launchpad.net/~linaro-infrastructure/cbuild/cbuild-scheduler_c
> build-lava/files/head:/queue/lava-panda-mock/ lava-test-shell script with
> actual commands to run for build is also served by CBuild frontend based on
> a template in that dir.
> 
> Currently, sandbox defines 3 test queue for LAVA integration:
> 
> lava-panda - build something on panda (tested only with gcc, needs more
> work)
> 
> lava-panda-mock - doesn't really compiles stuff, just downloads snapshot
> of previous gcc build. This allows for quicker (~15min) turnaround
> during testing, if you test snadbox, please use this queue.
> 
> lava-qemu-mininal - for local development with even shorter turnaround,
> won't work on sandbox.
> 
> 
> If you have any feedback on the architecture above, please share it.
> Otherwise, we're proceeding to support it in cbuild-tools.

So I do have some Lava issues - which are probably mostly due to Lava terms 
not being what I would expect them to mean:

The following Link is to the 'test results bundle'
 https://validation.linaro.org/lava-
server/dashboard/streams/anonymous/cbuild/bundles/9c87b6a32ef38e06d081f12f115c08e79ce89f8b/3df9cc54-60ec-484b-91bf-
cc4d34e3a494/

This shows four test cases - which reflect the historic build steps shown under 
'Details' in the historic Scheduler (gcc-configure, gcc-build, gcc-install, 
cbuild-global)

So currently these seem to reflect stages in the build process, rather than 
actual test results.  Eventually you will run the 'gcc-testsuite' build stage 
which actually does the regression testing (all 100K+ of tests) and I don't 
expect that to succeed usually (in terms of make check returning 0), although 
it will succeed in running the testsuite.

What is the intention here?  Are we going to have Lava be the high-level 
builder, and so its 'tests' are each of the build steps, and then the 
testsuite analysis is done elsewhere?  This is the current setup (see 
http://cbuild.validation.linaro.org/helpers/testcompare/gcc-
linaro-4.6-2012.09/logs/x86_64-precise-cbuild367-oort3-x86_64r1/gcc-
testsuite.txt - except this is currently returning an Internal Server Error).
Or is the intention for Lava to handle all of the gcc-testsuite results 
individually?

Thanks,

Matt

-- 
Matthew Gretton-Dann
Toolchain Working Group, Linaro

_______________________________________________
linaro-validation mailing list
[email protected]
http://lists.linaro.org/mailman/listinfo/linaro-validation

Reply via email to