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