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

Steven Chamberlain steven at pyro.eu.org
Sun Mar 6 14:02:24 UTC 2016


Hi,

Since kfreebsd is heavily reliant on sysvinit, this sounds like good
news to me!

Depending how this turns out, I possibly could run equivalent jobs on
kfreebsd, in parallel with whatever is put on jenkins.d.n

Simon Richter wrote:
> Interesting challenges:
> 
>  - Can we boot a VM from file system images that are artifacts from
> another build?

I don't understand exactly the purpose of this, but:
  * yes, one job could wget the artifacts from another one
  * or, a single Jenkins job could run Qemu more than once
    (first instance boots from /dev/sda, to initialise /dev/sdb,
    then the second job boots /dev/sdb)
  * or you could create just an initramfs (without using Qemu),
    then have Qemu boot that, no disk image required

>  - How to verify that the system in the VM booted correctly
> 
> Current idea: build a custom service that runs pstree, magically sends
> it to the build log, and then compare the output against the expected value.

Qemu can redirect the system console, or a serial port, to stdout and
all that can be logged or parsed by the Jenkins job runner.

You likely want sysvinit to start some services.  Depending on Qemu
network setup, you could ssh into it after booting it, to run tests and
log/parse the output.

Or use `nmap -sV` to scan all ports for running services?

Or if you start an X session greeter, even send keystrokes to log in
and launch applications, while making a cool video and OCR'ing what's
on-screen...
https://anonscm.debian.org/cgit/qa/jenkins.debian.net.git/tree/bin/g-i-installation.sh#n479

>  - Can we somehow generate an APT repository from an Alioth project?
> 
> When someone commits to the sysvinit repo, I'd like to build the
> packages (probably easy), then create something that debootstrap can
> access, ideally as an artifact (tar archive of repo?)

It is easy to trigger a package build in Jenkins after a Git commit;
the .debs would be available to wget from some other job, or you could
generate a proper APT repository using reprepro?  (the rebootstrap
scripts do the latter)

> I think step one should be simple transition tests:
> 
> 1. install a system with debootstrap
> 2. transition to sysvinit
> 3. transition back to systemd

Similarly on kfreebsd we should test openrc, and whether we can
transition to/from it...

> 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.

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.

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/37010dea/attachment.sig>


More information about the Qa-jenkins-dev mailing list