[Qa-jenkins-dev] Simon Richter: Why sysvinit?

[Steven Chamberlain]

> Simon Richter wrote:
> > I think step one should be simple transition tests:
> > 
> > 1. install a system with debootstrap
> > 2. transition to sysvinit
> > 3. transition back to systemd
> 
> > These should probably be three different projects, so we can reuse the
> > installed system at any point as an artifact, but that's something
> > someone more experienced with Jenkins might know better.
 
Steven Chamberlain wrote:
> I've noticed a tendency for jenkins.d.n jobs to be quite large and test
> many things within a single job.  Not sure if that's deliberate or just
> the way the tests evolved.  There may be advantages to smaller jobs, but
> OTOH when the result depends in inputs coming from other jobs, that too
> can be confusing to keep track of.

Smaller jobs sound good, as you can re-use the artifacts in other jobs
instead of duplicating work/code.

It is probablhy hard work to split complex jobs into smaller ones later.
And knowing that even simple jobs are going to get more complexity added
to them over time, I agree with having separate jobs like you said:

  1. debootstrapping a sid chroot:  that is a useful test in itself, I'd
do that every 6 hours - and the output (tarball?) is useful as a basis
for countless other tests, instead of them each running debootstrap
themselves.

It is important to catch issues early to avoid giving bad inputs to
other tests.  Make sure that /job/${job}/ws/chroot.tgz always points
to a *successfully* debootstrapped chroot so that a failure doesn't
cascade into other tests.

It also doesn't have to be just sid.  You could parameterise this (and
dependants) to check other suites too maybe.

Job "2" could be broken into at least three functions, or separate
shellscripts perhaps:

  2a. transition to sysvinit:  fetches 1. as its input.  Maybe have some
way to identify the input used;  I think `wget -N ... ; ls -al chroot.tgz`
would show the timestamp of the remote file in the log.

  2b. do whatever is needed to boot it - either use it as an initramfs,
turn it into a bootable image, or start it in some kind of a container.
(This part may be arch-specific, I would do something different here on
kfreebsd than you would on linux;  you may also need something different
for linux-armhf vs. linux-amd64;  or you may just want to test various
methods in any case, chosen via some parameter?).

  2c. install sysvinit, run some tests, and preserve the output as a
basis for other tests.  (If this is just ssh'ing into a running VM, it
is not arch-specific).
 
  3. transition to systemd - takes 2. as its input

  4. future test:  transition to openrc?  could take the output of
     job 1. or 2.

You've got me excited to work on this now...  I may as well just
implement the above on kfreebsd and leave you to only write the
tests and the linux-specific part?

Regards,
-- 
Steven Chamberlain
steven at pyro.eu.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/qa-jenkins-dev/attachments/20160306/6fc3d9d7/attachment.sig>