Re: [kernelci] proposal to build Debian images for every test suite (pull #24/kernelci-build-staging)

["Ana Guerrero Lopez" <ana.guerrero@collabora.com>]

On 11/05/18 07:23, Tomeu Vizoso wrote:
 > On 05/10/2018 05:41 PM, Kevin Hilman wrote:
 >> Tomeu Vizoso <tomeu.vizoso@collabora.com> writes:
 >>
 >>> On 05/10/2018 03:04 AM, Kevin Hilman wrote:
 >>>> "Tomeu Vizoso" <tomeu.vizoso@collabora.com> writes:
 >>>>
 >>>>> Hi,
 >>>>>
 >>>>> below I give my opinion on a few comments, but it's Ana who is 
leading
 >>>>> now this work.
 >>>>>
 >>>>> On 05/08/2018 01:09 AM, Kevin Hilman wrote:
 >>>>>> "Ana Guerrero Lopez" <ana.guerrero@collabora.com> writes:
 >>>>>
 >>>>>> IMO, what I think would be very helpful at least for initial 
review and
 >>>>>> discussion, is to see an initial PR that only has the "basic" 
build, and
 >>>>>> ideally also generates a minimal, tiny ramdisk from the same build
 >>>>>> (e.g. with 'update-initramfs -c -k min' )
 >>>>>>
 >>>>>>> The pull requests includes three things: three jenkinsfiles, 
debos files
 >>>>>>> and two Dockerfiles.
 >>>>>>>
 >>>>>>> The jenkinsfiles are the smallest possible since all the code 
creating
 >>>>>>> the pipeline is in the shared library. There are two parts: one 
with the
 >>>>>>> job name - that will be used by the resulting images, the
 >>>>>>> destination
 >>>>> arches
 >>>>>>> and the run-time dependencies that need to be added to the image.
 >>>>>>> There is also the debos file name but this should be removed if 
we always
 >>>>>>> use the same debos configuration.
 >>>>>>> The second part "build_test_suite" is for building the test 
suite code.
 >>>>>>> This is on purpose a shell script that must create a cpio.gz 
tarball
 >>>>>>> with the name rootfs-built-${NAME}-${ARCH}.cpio.gz
 >>>>>>> The idea is to be able to add and modify quickly test suites 
without
 >>>>>>> knowing too much about jenkins.
 >>>>>>
 >>>>>> I'm not sure about the "build_test_suite" approach.
 >>>>>>
 >>>>>> AFAICT, both the _igt and _v4l2 jobs are basically doing the 
same thing
 >>>>>> as "basic", and then essentially installing a bunch more files 
on top.
 >>>>>
 >>>>> The difference is only in the dependencies. Both test suites are in
 >>>>> the fat side and have several dependencies that otherwise aren't
 >>>>> needed. That said, a basic image that contains all of them might 
still
 >>>>> not be too big.
 >>>>
 >>>> IMO, it's better to go for a single, shared base image with
 >>>> dependencies.  Building a new rootfs for every test suite sounds 
like a
 >>>> scalability problem to me.
 >>>
 >>> Well, only the fatter test suites would need their own rootfs. So far
 >>> only IGT and V4L2 have a fair amount of dependencies. But still we
 >>> could probably build a single image for both that isn't too big to be
 >>> used as a ramdisk.
 >>
 >> OK, I think we should start with that.
 >
 > What do you think about that, Ana?

I'm fine having a single image with these two test suites, if eventually
this not convenient we can always change it. However, now we have more
or less agreed on a job creating the "basic" images, how do you envisage
we should be creating the images with the test suites?

My proposal is installing the build and run dependencies via extra_packages
in the Jenkinsfile and then building the test suite directly against the
new created image with script run by debos directly. This will avoid
the merge step, although the strip/crush might need a bit of work
for making sure the resulting ramdisk is still small.
The advantage is adding/modifying the test suites doesn't require a lot
of knowledge of jenkins or even debos.

[...]
 >> But I agree, for scalability, secondary storage is a major PITA.
 >> However, maybe for a subset of devices that we want to test that way, we
 >> should make it easy.
 >>
 >> So, what about this: From a single base debian image, we create
 >>
 >> 1) minimal (~2M) initramfs
 >>
 >> This should have pivot capabilities, and this is what Ana is doing today
 >> with 'update-initramfs -c -k min'
 >>
 >> 2) small "basic" ramdisk
 >>
 >> This is the base image *after* the strip/crush steps.  Basically, the
 >> "basic" that Ana is building today.
 >>
 >> 3) full rootfs for secondary storage (e.g. MMC, NFS, NBD)
 >>
 >> The base image without all the strip/crush removed, so it still has the
 >> ability to install packages etc.
 >>
 >> This should be available in a few formats: .cpio.gz, .tar.xz, .ext4.xz
 >>
 >> This would also be the pivot destination when using an initramfs.
 >
 > Sounds good!

Yup. I added the images listed in 3). So right now we have for every arch:
1) minimal initramfs: initrd.cpio.gz
2) small basic ramdisk:  rootfs.cpio.gz
3) full rootfs in several formats:  full.rootfs.cpio.gz ,
full.rootfs.tar.xz  and  rootfs.ext4.xz

Cheers,
Ana