[squeak-dev] Squeak CI Job status

Frank Shearar frank.shearar at gmail.com
Tue Jan 21 11:18:46 UTC 2014


On 21 January 2014 00:58, David T. Lewis <lewis at mail.msen.com> wrote:
> On Mon, Jan 20, 2014 at 05:32:51PM -0700, Jeff Gonis wrote:
>> Hi Folks,
>
> Hi Jeff,
>
> Thanks for looking into this, I think it is important to maintain this
> server and keep it producing meaningful tests.
>
>>
>> I was taking a look at the build.squeak.org server and it seemed like there
>> was a lot more red than green and I thought that I should at least start
>> contributing to trying to fix that. I added a project a while back to show
>> performance data from the image and it seemed to putting out some decent
>> data, at least from a trendline perspective, for the last little while.
>> Squeak was getting quite a bit faster from about the ~200 run of the
>> project to #380 before it popped back up.  I'll investigate the change in
>> speed and see if I can figure out the regression.
>>
>> In the meantime however, the console output is showing that the actual
>> tests ran fine, but the "bundle install" command is failing because we
>> apparently don't have the appropriate ruby gem installed to run this
>> command.  Is this something I can fix via the Hudson web console or would I
>> need access to the build server to do so? Does anyone with more ruby
>> experience have a suggestion for this?

It doesn't fail, it just warns about libyaml. And since we don't use
any YAML stuff, I didn't bother "fixing" the problem. But I'm very
happy that someone other than me actually reads the console output!
Thanks!

(The relevant warning is this:

+ bundle install
/var/lib/jenkins/.rvm/rubies/ruby-1.9.3-p392/lib/ruby/1.9.1/yaml.rb:56:in
`<top (required)>':
It seems your ruby installation is missing psych (for YAML output).
To eliminate this warning, please install libyaml and reinstall your ruby.
)

Oh. No, you're talking about SqueakTrunkPerformance. I missed that, in
the sea of red :( That was just because the build wasn't configured to
use rvm. Fixed, and apologies for not fixing sooner.

>> Both of the FreeBSD Interpreter and CogVM build jobs seem to be failing on
>> the basis of being unable to use Git to checkout Frank's squeakci
>> repository. I am not sure if that can be remedied by updating the installed
>> software on the FreeBSD build slaves.

See below.

> The CogVM build job is maintained by me (independently of the actual Cog
> VM development). Is intended to verify code generation only, and the errors
> that you see there reflect an actual error in the code generation. Possibly
> the current error condition reflects some method that needs to be checked in
> to VMMaker for oscog. This is useful information, and the error messages in
> the workspace are real, so this is a good thing.
>
> The FreeBSD Interpreter job has never worked. It is apparently owned by
> nobody, and it seems to serve no useful purpose. I recall that it used to
> be failing due to an improperly configured slave server (a FreeBSD machine
> with duplicate and conflicting installations of UUID libraries I think)
> but now it fails for no reason that I can understand. If anyone feels any
> ownership for or interest in this job please speak up, otherwise I would
> be happy to have the job disabled.

All the FreeBSD jobs are owned by me :) They _do_ serve a useful
purpose, which is to say "it doesn't work on FreeBSD". The machine on
which those jobs run is being retired by its owner (I was but a
guest), so until I find a new FreeBSD node (volunteers welcome! No,
really!), I'll disable the jobs. I've already marked the sole node
(havnor) as offline.

>> Finally I wanted to ask about build machine coverage.  Do we still need a
>> mac osx build machine to use remotely with Hudson and what about a windows
>> machine?  I have recently come into some machines and I was wondering if
>> donating time on those two operating systems would be worthwhile? They are
>> respectively running the latest version of OSX and Windows 8.1. I am
>> assuming that our linux coverage is good.

I would love a Windows machine. LOVE. The current mac osx node (norst)
runs, er, Snow Leopard, I think. It would be very useful to have a
latest-and-greatest OSX because I don't plan on upgrading from Snow
Leopard.

> I would think that test coverage for the Squeak unit tests on Windows and
> Mac OS X is very important indeed, and it would be great if you are able
> to provide that.

Test coverage is... _inadequate_, I think would be the polite way of
putting it, both in the sense of our code having very low coverage,
and in the sense of the tooling. TestCoverage tells you nothing more
than that a method was run: there's no indication, for instance, that
anything _inside_ that method ran. Also, you can't run coverage over
anything in Kernel or a bunch of other places, because we always
perform self-brain-surgery.

frank

> Thanks,
> Dave
>
>
>>
>> Thanks for your help and time,
>> Jeff


More information about the Squeak-dev mailing list