Begriffs Buildfarm

EuAndreh eu at euandre.org
Sun Feb 7 21:26:14 UTC 2021


Joe Nelson <joe at begriffs.com> writes:

> Thinking how it might work... I see that QEMU provides a bunch of
> binaries named qemu-system-$x, where $x is a processor architecture.
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/emulators/qemu/pkg/PLIST?rev=1.46&content-type=text/x-cvsweb-markup
>
> Focusing on MIPS, there's the big-endian "qemu-system-mips" and
> little-endian "qemu-system-mipsel". We'd then find base ISOs matching
> the architectures. Picking, say, Debian, those would be:
>
> https://cdimage.debian.org/debian-cd/current/mips/iso-cd/debian-10.8.0-mips-netinst.iso
> https://cdimage.debian.org/debian-cd/current/mipsel/iso-cd/debian-10.8.0-mipsel-netinst.iso
>
> We could run the installer ISOs in QEMU with the -nographic flag, and
> hook the Expect tool to the tty to control the installation.
> https://core.tcl-lang.org/expect/index
> (In fact, we could interact with installer manually, and let
> "autoexpect" create the script to automate our actions.)
>
> Once there's an automated way to turn an operating system ISO into a
> QEMU disk image with the desired packages installed, then the next step
> is using that disk image to test our code.
>
> I was thinking we could somehow bundle the code to be tested into its
> own disk image on request, and attach the image to the QEMU guest
> machine as if it were a harddrive. Then have our Expect scripter log in
> to the guest, mount the drive, and run the build/test steps. That series
> of steps would probably need to be customized per OS.
>
> Thus each platform to test would need three things:
> 1. The base OS ISO
> 2. The custom installer runner script
> 3. The custom test runner script
>
> Starting with MIPS on Debian 10 might be a good test case, because aside
> from the hardware architecture it would be familiar. I can't get to this
> project right away -- still finishing up another thing -- but if you or
> another person on the list are able to make progress on it I'd love to
> hear about it.

Hmm, this all sounds strangely familiar... Oh, I know why! It might be
because those were the exact same thoughts I had on this, and what I did
start to hack on.

Here's the totally brittle, but worked on my machine (at least earlier
today it did) version of what you said:

  https://git.euandreh.xyz/autoqemu/

To setup it up, download and install an Alpine Linux image:

  $ ./configure --prefix=$HOME/.local
  $ make install
  $ autoqemu ssh alpine

There is not much to say, other than it is very similar to what you
described:

1. download the ISO from a specific version and architecture (I went for
   Alpine on x86_64 because that is what the blog post from ddevault
   uses [0]);
2. setup the installer with QEMU using -nographic and expect (I even had
   the idea of trying autoexpect, but I found it less helpful than I,
   uh, expected);

The ssh.exp [1] script is the next step. It is totally not working, as
it is just a copy from an earlier version of the install.exp [2] script.
This is probably the next step, and I plan on it just configuring the
minimum working SSH server, so that the next step of "setting up a base
environment" can be done with POSIX sh over SSH instead of expect.

The current installation is somewhat unstable, and I haven't figured out
why, yet. Since it sometimes works inside tmux and doesn't work on a
bare terminal, and vice-versa, I guess that it has somehow related to
QEMU tty is being seen by expect. TBH, I don't know much about this, but
I'm willing to figure it out somehow. Help here is very welcome here.

The good parts of this approach is that is could be useful for other
uses than POSIX testing some code, where automation of VMs is desired
but other tools aren't that good.

What I had in mind for this "AutoQEMU" project was to enable me to do:

  $ autoqemu ssh alpine

...and get an interactive SSH session on the OS, or:

  $ autoqemu ssh alpine alpine-posixify.sh

...and have the "alpine-posixify.sh" script setup the base environment
for running code. This way, autoqemu is decoupled from the "POSIX CI"
idea.

After that, the POSIX CI thing could have the minimum set of commands to
setup the base images, which would be a pre-defined set of what autoqemu
would do. This way, the 'buildfarm-image-run' part would become just:

  #!/bin/sh
  set -eu

  autoqemu ssh --snapshot alpine buildfarm-build

(Actually it would need to clone the repository, or get the source code
somehow, but that is besides the point.)

I plan to work on the ssh.exp [1] next, so that I can run those commands
and scripts interactively.

Help and suggestions are welcome :)

[0]: https://drewdevault.com/2018/09/10/Getting-started-with-qemu.html
[1]: https://git.euandreh.xyz/autoqemu/tree/etc/autoqemu/alpine/ssh.exp?id=fc018b8d358cae01e61cda5ca3833bc34c444c03
[2:] https://git.euandreh.xyz/autoqemu/tree/etc/autoqemu/alpine/install.exp?id=fc018b8d358cae01e61cda5ca3833bc34c444c03


More information about the Friends mailing list