Reimplementing CI with Rake: status report

I got fed up really quickly with writing shell scripts, so I started
an experiment to use Ruby's Rake to run tests.
https://travis-ci.org/frankshearar/squeak-ci/builds/5835209 shows the
latest build, which
* builds a custom Interpreter VM (because the CI runs on several
unsupported platforms - CentOS on build.squeak.org (unsupported
because it uses an ancient glibc) and Travis (unsupported because it's
an x86_64 platform)),
* use Cog if available,
* prepare a test image (update the image under test, load the HudsonBuildTools),
* and then run a bunch of external packages on a copy of the updated image.

In particular, we run AndreasSystemProfiler, Control, FFI, Nebraska,
Nutcracker, OSProcess, Quaternion, Phexample, RoelTyper, SqueakCheck,
Universes, WebClient, XML-Parser and Zippers against each of Squeak
4.3, 4.4 and 4.5. You can run this same build script on multiple
platforms: CentOS, Ubuntu 10.04, whatever Travis is running, Windows
7. It ought to work anywhere that Ruby works and the code compiles. I
haven't tested it on OS X yet, and it almost certainly won't work on
FreeBSD because the Interpreter doesn't compile there [1].

I still use the old shell scripts for the SqueakTrunk and
ReleaseSqueakTrunk jobs, but these could be replaced with Rake, simply
by running `rake release` instead of `rake test`.

frank

[1] http://build.squeak.org/job/SqueakTrunkOnInterpreterFreeBSD/18/console
shows an issue with libuuid (of course). This particular problem's
been solved on the Cog branch, but Eliot and I have yet to get Cog
compiling on FreeBSD (for other reasons).

On Wed, Mar 27, 2013 at 11:18:24AM +0000, Frank Shearar wrote:
>
> [1] http://build.squeak.org/job/SqueakTrunkOnInterpreterFreeBSD/18/console
> shows an issue with libuuid (of course). This particular problem's
> been solved on the Cog branch, but Eliot and I have yet to get Cog
> compiling on FreeBSD (for other reasons).

There is considerable background on the libuuid bug here:

  http://bugs.squeak.org/view.php?id=7358

Very likely your FreeBSD platform has the buggy library. If so, the problem
"goes away" if you compile the plugin internal. However, the resulting VM
will not work on another computer if the user does not have libuuid installed,
so this is not appropriate for officially distributed VMs.

Given that you are compiling a VM for your own use on your own server,
you can work around the library bug either by compiling the plugin internal,
or by simply deleting the external so.UUIDPlugin plugin after you compile it
(which is exactly what a typical user would need to do if s/he downloaded
an official VM and found that it crashed due to the libuuid bug).

I have not heard much about this bug recently, so hopefully the buggy
libraries are working their way out of the Linux ecosystem.

Dave

Yes, must find time to get back to this.  We need to find a FreeBSD kernel developer who understands the sigcontext issues.
--
best,

On 27 March 2013 17:22, Eliot Miranda <[hidden email]> wrote:
Sorry for not being clear; yes, it's the libc6:i386 issue. Some
platforms - Heroku's, in particular - don't let you install the
necessary bits. Travis CI gives you a clean virtual machine that they
throw away, so they let you run as root. So it's as easy as "apt-get
install libc6:i386" to get things working there. The horror of Heroku
clouded my thinking.

And I stand corrected regarding CentOS. It's the official Interpreter
binaries that don't work on whatever version of CentOS
build.squeak.org, because they need 2.14 or 2.15 and build.squeak.org
uses 2.11.

frank